tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Costin Manolache <cmanola...@yahoo.com>
Subject RE: Object pooling performance
Date Wed, 09 Jul 2003 16:04:38 GMT
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.

The "lifetime of the object" is a tricky one :-)

There are a lot of cases ( tomcat Request object, JST tags ) where the
object can very well live as long as the server. In almost any program 
there are a set of objects that are used a lot - where the object can be 
made mutable and reused. 

For short span objects - I agree, GC is better. But again, in most cases 
"short lifespan" of an object is by programming it to be non-reusable,
and with a bit of work you can make it long-lived.



> 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

MimeHeaders in 3.2 had some performance problems, AFAIK we made a lot of
changes ( in both 3.3 and 5.0 )

Costin

> 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


Mime
View raw message