Re: Server-side. Performance Re: Netscape Support for XSL

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