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

[Paul Tchistopolskii <paul@xxxxxxx>]

> >  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