tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Glenn Nielsen <gl...@mail.more.net>
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.

Regards,

Glenn

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 [mailto:glenn@mail.more.net]
>>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
>>of
>>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
>>performance
>>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
>>increase.
>>
>>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.
>>
>>Regards,
>>
>>Glenn
>>
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
> 


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


---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org


Mime
View raw message