You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Antonio Gallardo <ag...@agsoftware.dnsalias.com> on 2003/03/05 19:37:13 UTC

Jetty performance....

Hi:

I finally ported an application to Jetty. I feel like Jetty is slower than
Tomcat. I tried to find some info about Jetty performance tweaking but no
where I found it. Also there in amazon.com is no book about Jetty.

Can someone explain how to improve Jetty performance?

Best Regards,

Antonio Gallardo.



Re: Jetty performance....

Posted by Antonio Gallardo <ag...@agsoftware.dnsalias.com>.
OK, thanks for the answer. That I read between lines is:

1-Jetty is there just to show newcomers the power of cocoon. A simple and
clear "run and try" test.

2-For production, choice the servlet container you want to use. Any
servlet container (Tomcat. Jetty, etc.) is your choice.

I feel now it is clear. ;-).

Best Regards,

Antonio Gallardo


Pier Fumagalli dijo:
>
> A note here that I want to make sure will remain in the mail archive:
> the version of Jetty shipping with Cocoon is a stripped-down embedded
> version, it is NOT the full distribution. The full distribution includes
> support for stuff like Java 1.4 NIO, which will increase performances
> under that environment, a lot of documentation, configuration snippets
> and examples: Jetty (whole) is not what we ship as an embedded solution
> for running Cocoon straight out of the downloaded archive.






Re: Jetty performance....

Posted by Pier Fumagalli <pi...@betaversion.org>.
On 7/3/03 21:50, "Miles Elam" <mi...@pcextremist.com> 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



Re: Jetty performance....

Posted by Miles Elam <mi...@pcextremist.com>.
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.

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.

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.  Antonio is definitely 
right about the lack of complete documentation right away.

- Miles



Re: Jetty performance....

Posted by Suhail M Ahmed <il...@mac.com>.
Hi

On Saturday, March 8, 2003, at 06:27  PM, Pier Fumagalli wrote:

> On 7/3/03 18:14, "Antonio Gallardo" <ag...@agsoftware.dnsalias.com>
> wrote:
>
>>> "Antonio Gallardo" <ag...@agsoftware.dnsalias.com> wrote:
>>>
>>>> Hi Luca!
>>>>
>>>> I seems like nobody is interested in this topic. I cannot believe 
>>>> it!
>>>> :-(
>>>
>>> Well, it's not really related to Cocoon... Cocoon ships with Jetty 
>>> for
>>> its "build run" environment, nothing that I would run on a production
>>> (or even development server).
>>
>> The point here is how we can get most from Jetty. I know that Cocoon 
>> is
>> not Jetty, but including Jetty into Cocoon is promoting the use of 
>> Jetty.
>
> Antonio, no, you got it all around! :-) :-) Including Jetty in Cocoon 
> is
> promoting the use of Cocoon! I explain, you donwload Cocoon, and now 
> it's
> quite a big fella, the CVS checkout, tarred and gzipped is something 
> around
> the lines of 28 megabytes.
>
> If to play around with it, and see that you like it, you have to 
> download
> another package, the servlet container, which is an EXTRA 6.5 
> megabytes of
> tar.gz in case of tomcat, or 5.7 megabytes in case of Jetty (not much
> difference in the "official" distributions, huh?) you'll get _severely_
> upset, also because, considering that once you've downloaded it, you 
> have to
> figure out HOW you're going to make the two work together.

there is an old maxim about how you cannot please everybody. I for one 
am not pleased with Jetty because I now have two containers sitting on 
my machine.  how different is typing .\catalina run from .\cocoon 
servlet? The fact that you have to copy a war file from your build 
directory to the webapp directory? Jetty (or any other bundled web 
container) would make sense for those developers who have no knowledge 
of servlet containers and are interested only in cocoon. Personally I 
just want a war file.

> In the documentation, nowhere, you'll see that Jetty is the 
> "preferred" way
> of running Cocoon.

On a humorous note, I guess that what Microsoft said about IE when they 
bundled that browser ;-)

Cheers
Suhail


Re: Jetty performance....

Posted by Pier Fumagalli <pi...@betaversion.org>.
On 7/3/03 18:14, "Antonio Gallardo" <ag...@agsoftware.dnsalias.com>
wrote:

>> "Antonio Gallardo" <ag...@agsoftware.dnsalias.com> wrote:
>> 
>>> Hi Luca!
>>> 
>>> I seems like nobody is interested in this topic. I cannot believe it!
>>> :-(
>> 
>> Well, it's not really related to Cocoon... Cocoon ships with Jetty for
>> its "build run" environment, nothing that I would run on a production
>> (or even development server).
> 
> The point here is how we can get most from Jetty. I know that Cocoon is
> not Jetty, but including Jetty into Cocoon is promoting the use of Jetty.

Antonio, no, you got it all around! :-) :-) Including Jetty in Cocoon is
promoting the use of Cocoon! I explain, you donwload Cocoon, and now it's
quite a big fella, the CVS checkout, tarred and gzipped is something around
the lines of 28 megabytes.

If to play around with it, and see that you like it, you have to download
another package, the servlet container, which is an EXTRA 6.5 megabytes of
tar.gz in case of tomcat, or 5.7 megabytes in case of Jetty (not much
difference in the "official" distributions, huh?) you'll get _severely_
upset, also because, considering that once you've downloaded it, you have to
figure out HOW you're going to make the two work together.

And this ONLY to "try out" cocoon, and explore its beauty.

Now, I believe that including a shrinked out version of Jetty with only the
functionality we need, a pre-configured environment, and the ease to invoke
"./cocoon.sh" and have it running is worth an extra 500 kilobytes of jar.

Note, in cocoon we embed a very restricted edition of Jetty, only the core
JAR, not all that comes with it, the size is one thenth of the ENTIRE
distribution... Jetty is designed to be embeddable, and allows us to show
our users the incredible functionality of Cocoon, increasing slightly our
download size.

In the documentation, nowhere, you'll see that Jetty is the "preferred" way
of running Cocoon.

> Many people think about that (please check the mail to this thread before
> yours). When you started talking about Jetty, Tomcat was a silent standard
> for people using Cocoon. Everybody recommend you the use the Tomcat. Now
> we are promoting Jetty.

We (this group) are _not_ promoting Jetty, we're _using_ it... I (Pier
Fumagalli, good friend of Greg Wilkins, Jetty's author) am promoting it
because it had several advantages in my own environment over Tomcat.

I (Pier Fumagalli, working for VNU) use Jetty in production on
http://www.vnuservices.co.uk/ and am extremely pleased with it.

I (Pier Fumagalli, member of the Cocoon community) am fully aware that
Cocoon must show off its potentiality to users by embedding a servlet
container, but am aware of, and promote, that Cocoon _must_ run on ALL
(most) Servlet containers and that this is one of our main goals.

> I said OK! You showed us the following gain over
> Tomcat:
> 
> Smaller!  (I agree)
> Faster!   (I cannot currently agree. :-( )
> 
> I was trying to find some tips about how to get the most from Jetty, but
> nowhere info. There are no books written about Jetty. Please note I am not
> trying to attack Jetty. I believe this is the correct way. But as me many
> people here dont see the gain of performance. Some people runs on Windows
> and some runs Linux (like me).
> 
> I want that this negative stuff go away. But for current purpose I am
> seriously think in switching back to Tomcat. I need an application that
> performance good in front of users. If the container is a big hairy
> monster the users does not care. They only see the response time. I know
> what you said in your mail. I will (maybe) do a very bad error in
> switching back. But I dont see a solution in the near future. Can you
> recommend some docs for trying to get the most from Jetty? Really this is
> the purpose of this thread. :-)

I cannot recommend any book, because there aren't any... I _know_ Jetty as
well as Tomcat because I developed and hacked around BOTH containers, and
know that in _my_ environment, there's no chance I'm going to use Tomcat.

If you feel that Jetty doesn't work for you, fair enough, use Tomcat, as a
member of this community all I can tell you is "YES, Cocoon runs perfectly
with Tomcat"...

>>> The question is:
>>> What we gain if the applications run slow under Jetty?.
>> 
>> That's your measurement... I've noticed a quite substantial performance
>> increase...
> 
> What plataform are you using? I am using Red Hat Linux 8.0, PostgreSQL,
> and Cocoon 2.1 HEAD. The iron is: AMD Athlon XP 1.7, 512 MB, 60 GB.

Several (VNU has currently 7 live servers and personally I manage another 4
machines): all around Sun or Apple hardware, with the occasional PC running
Win2k and Linux...

For what I need to do, with my configurations, I've seen improvements (and I
can tell you how and why, if you want) using Jetty compared to other servlet
containers (not only Tomcat, but WebSphere, Orion and ServletExec as well).

>>> The only positive answer is that we "save" some cents in storage on
>>> the hard disk, but since it is too cheap.... I think our saving are
>>> less than 1 cents or low. :-D
>
> If continued in this rethoric, then if a HD of 60GB cost US$ 140.00 and
> Jetty use 75MB less that Tomcat, we gain: 17.08 cents! ;-) Its better.

You'll gain _MUCH_LESS_ than that... Tomcat is 6.5 megs, Jetty 5.7 when you
download the official distributions.

A note here that I want to make sure will remain in the mail archive: the
version of Jetty shipping with Cocoon is a stripped-down embedded version,
it is NOT the full distribution. The full distribution includes support for
stuff like Java 1.4 NIO, which will increase performances under that
environment, a lot of documentation, configuration snippets and examples:
Jetty (whole) is not what we ship as an embedded solution for running Cocoon
straight out of the downloaded archive.

>> You're more than welcome to go and download Tomcat, and install the
>> cocoon web-application onto it. I believe, though, it would be a _huge_
>> mistake if we thought about adding another 24 megs of code just to ship
>> a servlet container with the Cocoon distribution...
> 
> Sorry but I dont share this opinion. I dont need to download Tomcat it is
> running since December without problems of any kind on a little more
> capable machine as I described above. What I am trying to said is that
> today saving 24 MB is nothing (less than 6 cents.).

I think it would be a _big_ mistake if this community would put in CVS all
jars required to run Tomcat, as we do with Jetty... The figure of 24 megs is
probably not _that_ real (only the unpacked binary dist), but as an
ex-Tomcat developer I can assure you that you can't strip out much without
preventing functionality... That will increase severely our CVS size (by
some megs), and also our future binary distributions... That's all I'm
concerned about.

>> That's my thought, at least...
> 
> I and many people here want to have the same thought as you. Please show
> us the shine! :-)

The "shrine" for all Jetty world is in its mailing list:
jetty-discuss@yahoo.com, if I'm not wrong! :-) :-)

    Pier


Re: Jetty performance....

Posted by Antonio Gallardo <ag...@agsoftware.dnsalias.com>.
> "Antonio Gallardo" <ag...@agsoftware.dnsalias.com> wrote:
>
>> Hi Luca!
>>
>> I seems like nobody is interested in this topic. I cannot believe it!
>> :-(
>
> Well, it's not really related to Cocoon... Cocoon ships with Jetty for
> its "build run" environment, nothing that I would run on a production
> (or even development server).

The point here is how we can get most from Jetty. I know that Cocoon is
not Jetty, but including Jetty into Cocoon is promoting the use of Jetty.
Many people think about that (please check the mail to this thread before
yours). When you started talking about Jetty, Tomcat was a silent standard
for people using Cocoon. Everybody recommend you the use the Tomcat. Now
we are promoting Jetty. I said OK! You showed us the following gain over
Tomcat:

Smaller!  (I agree)
Faster!   (I cannot currently agree. :-( )

I was trying to find some tips about how to get the most from Jetty, but
nowhere info. There are no books written about Jetty. Please note I am not
trying to attack Jetty. I believe this is the correct way. But as me many
people here dont see the gain of performance. Some people runs on Windows
and some runs Linux (like me).

I want that this negative stuff go away. But for current purpose I am
seriously think in switching back to Tomcat. I need an application that
performance good in front of users. If the container is a big hairy
monster the users does not care. They only see the response time. I know
what you said in your mail. I will (maybe) do a very bad error in
switching back. But I dont see a solution in the near future. Can you
recommend some docs for trying to get the most from Jetty? Really this is
the purpose of this thread. :-)

>
>> The question is:
>> What we gain if the applications run slow under Jetty?.
>
> That's your measurement... I've noticed a quite substantial performance
> increase...

What plataform are you using? I am using Red Hat Linux 8.0, PostgreSQL,
and Cocoon 2.1 HEAD. The iron is: AMD Athlon XP 1.7, 512 MB, 60 GB.
>
>> The only positive answer is that we "save" some cents in storage on
>> the hard disk, but since it is too cheap.... I think our saving are
>> less than 1 cents or low. :-D
If continued in this rethoric, then if a HD of 60GB cost US$ 140.00 and
Jetty use 75MB less that Tomcat, we gain: 17.08 cents! ;-) Its better.
>
> You're more than welcome to go and download Tomcat, and install the
> cocoon web-application onto it. I believe, though, it would be a _huge_
> mistake if we thought about adding another 24 megs of code just to ship
> a servlet container with the Cocoon distribution...

Sorry but I dont share this opinion. I dont need to download Tomcat it is
running since December without problems of any kind on a little more
capable machine as I described above. What I am trying to said is that
today saving
24 MB is nothing (less than 6 cents.).

>
> That's my thought, at least...

I and many people here want to have the same thought as you. Please show
us the shine! :-)

Best Regards,

Antonio Gallardo
>
>     Pier




Re: Jetty performance....

Posted by Pier Fumagalli <pi...@betaversion.org>.
"Antonio Gallardo" <ag...@agsoftware.dnsalias.com> wrote:

> Hi Luca!
> 
> I seems like nobody is interested in this topic. I cannot believe it! :-(

Well, it's not really related to Cocoon... Cocoon ships with Jetty for its
"build run" environment, nothing that I would run on a production (or even
development server).

> The question is:
> What we gain if the applications run slow under Jetty?.

That's your measurement... I've noticed a quite substantial performance
increase...

> The only positive answer is that we "save" some cents in storage on the
> hard disk, but since it is too cheap.... I think our saving are less than
> 1 cents or low. :-D

You're more than welcome to go and download Tomcat, and install the cocoon
web-application onto it. I believe, though, it would be a _huge_ mistake if
we thought about adding another 24 megs of code just to ship a servlet
container with the Cocoon distribution...

That's my thought, at least...

    Pier


RE: Jetty performance....

Posted by Antonio Gallardo <ag...@agsoftware.dnsalias.com>.
Hi Luca!

I seems like nobody is interested in this topic. I cannot believe it! :-(

The question is:

What we gain if the applications run slow under Jetty?.

The only positive answer is that we "save" some cents in storage on the
hard disk, but since it is too cheap.... I think our saving are less than
1 cents or low. :-D

Best Regards,

Antonio Gallardo

>> -----Original Message-----
>> From: Antonio Gallardo [mailto:agallardo@agsoftware.dnsalias.com]
>> Sent: Wednesday, March 05, 2003 7:37 PM
>> To: cocoon-dev@xml.apache.org
>> Subject: Jetty performance....
>
>> I finally ported an application to Jetty. I feel like Jetty is slower
>> than Tomcat. I tried to find some info about Jetty performance
>> tweaking but no where I found it.
>
> I've found it to be slower too :(
> Moreover, its doc is even thinner than Tomcat's.
>
> Regards,
>
> ---------------------------------------------
>                Luca Morandini
>                GIS Consultant
>               lmorandini@ieee.org
> http://utenti.tripod.it/lmorandini/index.html
> ---------------------------------------------
>




RE: Jetty performance....

Posted by Luca Morandini <lu...@tin.it>.
> -----Original Message-----
> From: Antonio Gallardo [mailto:agallardo@agsoftware.dnsalias.com]
> Sent: Wednesday, March 05, 2003 7:37 PM
> To: cocoon-dev@xml.apache.org
> Subject: Jetty performance....

> I finally ported an application to Jetty. I feel like Jetty is slower than
> Tomcat. I tried to find some info about Jetty performance tweaking but no
> where I found it. 

I've found it to be slower too :(
Moreover, its doc is even thinner than Tomcat's.

Regards,

--------------------------------------------- 
               Luca Morandini 
               GIS Consultant 
              lmorandini@ieee.org 
http://utenti.tripod.it/lmorandini/index.html 
---------------------------------------------