On 7/3/03 21:50, "Miles Elam" <[EMAIL PROTECTED]> wrote:
> Found this: http://www.caucho.com/support/resin-interest/0211/0241.html
>
> Thought it might be interesting for others. It was for me. The last
> paragraph was most interesting to me.
>
> "/All in all, I think that Jetty, Resin and Tomcat must all be getting /
> pretty close to terminal /velocity for serving servlets. We are all
> maxing out just under or over /
> 2000 servlet requests /a second on my hardware - I doubt there is much
> scope of going much beyond /
> that and I don't /think we'll see 3000 unless I get a new network :-)"/
> //
>
> //The discussion moves on to talk about optimizations related to flush()
> et al with the general thoughts being that Resin is somewhere between
> slightly faster to much faster than Jetty. Note: Resin mailing list.
The original message was from Greg, the main author of Jetty ! :-) And if he
says so! :-) Actually what I noticed is slightly different: I noticed that
Jetty is slightly slower than Tomcat 4.1.18 (my something around 1/2%) but
it uses FAR less memory.
FAR less memory, means FAR garbage collector which in MY own environment
(VNU's production) means FAR more speed and less OutOfMemoryException(s). We
currently give up to 3 GIGS of ram to the VMs to process requests, thank you
JSPs! :-)
> Now then, with output of 2000 requests a second, how much do you really
> worry about the implementation of the service() method? Wouldn't time
> be better spent profiling your XSLT and tweaking Cocoon's cache lookup
> algorithms? It just seems to me that once requests become a
> sufficiently small number given the fraction
>
> engine overhead / Cocoon processing
>
> does it matter that much? If someone can point me to where all logic
> leading up to the service() method is approaching the processing time of
> after Cocoon's service() method is called, I'd be very interested
> indeed. As it stands, splitting up your sitemap into multiple
> subsitemaps (for example) so that the number of matches is reduced would
> be a greater boon to performance.
The overhead in processing a request is important, but not that much when
you compare it with Cocoon times, and the I/O is pretty much the same on all
containers... As I said before, our problem with Tomcat was that it was
allocating way too much memory, and if that is fine in an environment with
medium/medium low Req. Per. Sec., it's kind of bad when you hit the
high/very high range (in the order of minimum continued RPS around 100 like
we do). The garbage collector simply runs too much, and we hit on peak (600
RPS) some nasty OutOfMemory exceptions...
And in Tomcat, when you hit the OOM exception, your HTTP listener dies...
> For me, the simplicity of Jetty is a boon to me. (Thank you Stefano and
> Pier for encouraging me to look at it.) However, has anyone else tried
> to compile 4.2.x from source? The binary download works fine, but
> default build environment seems hosed to me.
I do it all the time... We use CVS head because of some fixes, and because I
patched a couple of very-specific VNU requirements in...
> Antonio is definitely right about the lack of complete documentation right
> away.
Once you understand that the source reference for your configuration file is
the JavaDOC, then you're in the inner shrine, and nothing will prevent you
from actually tuning Jetty to however you want (and that is essential for
us)... But we're getting off-topic here! :-)
Pier
