tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Glenn Nielsen <>
Subject Re: Object pooling performance
Date Tue, 08 Jul 2003 17:05:26 GMT
The optimal solution would be the ability to enable/disable each type of
object pooling with a config parameter so that tomcat admins can tune Tomcat
to perform best for their OS/JVM.

Like you can currently do with Jasper and JSP tag pooling.



Marc Saegesser wrote:
> Another thing to consider when evaluating object pooling is the expected
> lifetime of the objects.  On modern JVMs with generational memory stores,
> objects with a short lifespan (say the duration of a single HTTP request)
> will probably never leave the nursery.  Pooling these kinds of objects
> usually degrades performance rather than improving it.
> I've just finished some performance research on Tomcat 3.2 (I know, I
> know...) and one of the things I found was that the o.a.u.MimeHeaders and
> related classes were a huge performance bottleneck.  The existing code went
> to great lengths to avoid creating 'garbage' and the result was code that
> was very slow.  I replaced it with a much simpler set of classes that
> basically ignored the GC impact and saw a 15% performance improvement under
> load.
> Marc
>>-----Original Message-----
>>From: Glenn Nielsen []
>>Sent: Tuesday, July 08, 2003 9:25 AM
>>To: Tomcat Developers List
>>Subject: Object pooling performance
>>Remy Maucherat wrote:
>>>Bill Barker wrote:
>>>>Now, if we could only convince the Jasper developers of this ... ;-).
>>>Tag pooling is definitely not the same situation and use case as session
>>>pooling. Tag pooling *is* useful in many cases.
>>There are a number of things to consider when evaluating the performance
>>object pooling.
>>The performance hit of obtaining/recycling an object can be greater than
>>instantiating a new object, it depends on the JVM.
>>But you also have to consider the impact on GC.  One big impact on
>>of Tomcat is the frequency of and the time it takes to do incremental and
>>Full GC's.
>>Full GC's can be especially nasty. In most JVM's a Full GC freezes
>>processing of
>>requests by Tomcat.  I would rather have a slight performance hit from
>>recycling objects
>>than see the frequency of Full GC's increase and the time they take
>>I saw a huge performance boost when recycling of JSP custom tags was
>>implemented in
>>Jasper.  Most of that performance boost comes from reducing the frequency
>>and length
>>of GC's.
>>To collect GC data add the -verbose:gc arg to java when you start Tomcat.
>>To unsubscribe, e-mail:
>>For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

Glenn Nielsen    | /* Spelin donut madder    |
MOREnet System Programming               |  * if iz ina coment.      |
Missouri Research and Education Network  |  */                       |

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message