This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
Re: Server-side. Performance Re: Netscape Support for XSL
- To: xsl-list at mulberrytech dot com
- Subject: Re: Server-side. Performance Re: Netscape Support for XSL
- From: Matt Sergeant <matt at sergeant dot org>
- Date: Sat, 20 May 2000 08:59:19 +0100 (BST)
- Reply-To: xsl-list at mulberrytech dot com
On Fri, 19 May 2000, Paul Tchistopolskii wrote:
> Well .. That means - still no need in storing xml document in internal cache.
> Caching strategy could be pretty trivial :
[snip]
Well it is fairly trivial. I didn't say otherwise. You've missed some
points, like the need for AxKit and Cocoon to transparently cache not just
XSLT transformations, but other languages in the mix too (XSP, for
example).
> > This allows AxKit to achieve delivery rates of 100m page views a
> > day (nobody is running a site using AxKit that does that, but the point is
> > still valid), on the right hardware. I don't have any performance figures
> > for Cocoon, although I believe it's slightly slower than AxKit (but I'm
> > biased!).
>
> And I'm a bit suspicios about the 'right hardware'. ( Please see below ).
OK, here I have a PIII550. I'm running 3 httpd's (most servers run lots
more) because this is my development box and workstation. I also run
Oracle and Sybase concurrently on this same box. Standard IDE drives -
nothing special. I've benchmarked AxKit here at 10m requests/day. That
value scales up linearly, with both hardware and more httpds (to a certain
point).
> > AxKit is built in Perl using the Apache API, Cocoon is built as a
> > servlet. Which seems kindof backwards when Cocoon is part of the Apache
> > project ;-)
>
> So AxKit is mod_perl. Please corrent me if I'm wrong, but the biggest
> design problem of mod_perl ( which has signicifant impact on hps ) is
>
> - the load
> - how much RAM do you have
> - how complex is the perl application
>
> Briefly - mod_perl is not scalable ( and not easy for load-balancing ) .
That's just nonesense. Sounds like something a servlet vendor told you ;-)
Seriously - this has been fought out over and over. Real people are using
mod_perl on real projects. And it scales. Projects you may have heard of
like deja-news, the internet movie database, slashdot, and many more.
And servlet vendors have also been know to actually improve their products
to try and catch up with mod_perl!
> 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.
[snip some common mod_perl misconceptions]
> 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.
> 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?
While I enjoyed this, it's completely off topic here - mail me direct if
you want to rebutt.
--
<Matt/>
Fastnet Software Ltd. High Performance Web Specialists
Providing mod_perl, XML, Sybase and Oracle solutions
Email for training and consultancy availability.
http://sergeant.org http://xml.sergeant.org
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list