[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Server-side. Performance Re: Netscape Support for XSL
> > As far as I remember - we have 2 basic engines to run persistent server-side perl > > applications. mod_perl and FastCGI. FastCGI provides presistensy for > > perl code and perl data. mod_perl provides only persitency for perl precompiled > > bytecode. Righ? > > Wrong. This is the only technical point you are making in your letter and I'l be gald to get more explanations off-list, because I don't understand what in particular is wrong here. Is it wrong, for example, because I have not mentioned Velocity? > [snip some common mod_perl misconceptions] Nice. > > My claim is that: > > > > 1. Servlets architecture is more scalable and could be even > > more efficient in the case of complex applications. > > Your claim is not held up by the benchmarks I've seen. I'm not saying > mod_perl is always faster - it balances out. Java will kick mod_perl's ass > on complex loops, mathematical work, and some other fringe cases. mod_perl > will kick Java's ass by miles on database access (sorry, but JDBC drivers > are still playing catchup speedwise to DBI drivers - search dejanews for > relevant posts), and on string handling. I suggest some day you spend some time benchmarking HotSpot VM. Or just read some messages on Sun's web-board. From people who tried. Is the factor of 10 on JDBC interesting to you ( the marshalling has been changed in HotSpot, detailes are on sun's website.) ? Not talking about Jaguar yet. Notification. I have spend 1+ year with DBI/DBD ( mostly Oracle). In fact, long time ago I was the only person in the world who got somehow ported mySQL DBI:DBD to Windows. > > 2. Caching has nothing to do with servlets design and/or > > mod_perl design. > > > > Your original point was about 'performance penatly of java servlets'. > > The point I made was within the specific area of XSLT transforming > servlets - every one I've seen so far has not had a significantly strong > caching architecture. Why would they, when Cocoon - which is also a > servlet - offers so much more to the developer? I don't understand this point. What do you call 'significantly strong caching architecture'? Each XSLT servlet avoids stylesheet re-compilation. You mean that storing pre-generated HTML page and timestamp of XML file is 'significantly strong' ? It is 1 day of work. So the 'penalty' is to spend one day adding trivial caching? > While I enjoyed this, it's completely off topic here - mail me direct if > you want to rebutt. Sure, I want to know what in particular is wrong in my view, because unfortunately I got no technical information from your long letter. BTW - you forgot to mention yahoo. Should be powered by mod_perl also. Also there are much more VisualBasic applications than perl applications in this world. Does it say anything about scalability and efficiency of Visual Basic? I don't think so. Rgds.Paul. PS. Servlets are really more scalable than mod_perl and this is not because some vendor told it to me, but because I was used to write mod_perl code and I was used to write servlets. And I had a chance to compare. Did you ? 'Scaling' mod_perl application with some more hardware is not what I call 'scaling'. PPS. Maybe we understand the word 'scalable' in a different way? For example, I don't think the solution below is 'scalable'. Mod_perl. ApacheDBI You will want to use this module if you are opening several database connections to the server. Apache::DBI will make them persistent per child, so if you have ten children and each opens two different connections (with different connect() arguments) you will have in total twenty opened and persistent connections. After the initial connect() you will save the connection time for every connect() request from your DBI module. This can be a huge benefit for a server with a high volume of database traffic. You must not use this module if you are opening a special connection for each of your users. Each connection will stay persistent and in a short time the number of connections will be so big that your machine will scream in agony and die. If you want to use Apache::DBI but you have both situations on one machine, at the time of writing the only solution is to run two Apache/mod_perl servers, one which uses Apache::DBI and one which does not. XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|