tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Remy Maucherat <r...@apache.org>
Subject Re: Object pooling performance
Date Tue, 08 Jul 2003 19:55:49 GMT
Glenn Nielsen wrote:
> Remy Maucherat wrote:
> 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.

Well, I can't really do that right now (my test setup is dead since my 
laptop died ...). However, the session object itself is simply a 
container object. One of the main cost of creating the session is 
generating the id, not the object (IMHO). Since the recyling code is 
disabled in 4.1.24 due to security issues, and is very likely not the 
biggest cost during a session creation.

Overall, I think other factors are much more important that the session 
for GC. For example, the main pipeline is virtually GC free in TC 5.0. 
That isn't the case in TC 4.1, by a long shot. That's garbage being 
generated for each request, not once every 10s of requests. That's where 
the real difference for GC will be (IMO).

I think session recycling is not worth the security risk (and I'm 
usually the one pushing for optimizations :-)).

Remy


---------------------------------------------------------------------
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