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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
