You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by re...@apache.org on 2003/07/08 08:30:46 UTC
cvs commit: jakarta-tomcat-catalina/modules/cluster/src/share/org/apache/catalina/cluster/session SimpleTcpReplicationManager.java
remm 2003/07/07 23:30:45
Modified: modules/cluster/src/share/org/apache/catalina/cluster/session
SimpleTcpReplicationManager.java
Log:
- Remove session recycling, as well as the comments criticizing session
recycling.
Revision Changes Path
1.9 +4 -26 jakarta-tomcat-catalina/modules/cluster/src/share/org/apache/catalina/cluster/session/SimpleTcpReplicationManager.java
Index: SimpleTcpReplicationManager.java
===================================================================
RCS file: /home/cvs/jakarta-tomcat-catalina/modules/cluster/src/share/org/apache/catalina/cluster/session/SimpleTcpReplicationManager.java,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- SimpleTcpReplicationManager.java 18 Apr 2003 02:51:24 -0000 1.8
+++ SimpleTcpReplicationManager.java 8 Jul 2003 06:30:45 -0000 1.9
@@ -229,29 +229,7 @@
throw new IllegalStateException(sm.getString("standardManager.createSession.ise"));
- // Recycle or create a Session instance
- Session session = null;
- //modified to make sure we only recycle sessions that are of type=ReplicatedSession
- //I personally believe the VM does a much better job pooling object instances
- //than the synchronized penalty gives us
- synchronized (recycled) {
- int size = recycled.size();
- int index = size;
- if (size > 0) {
- do
- {
- index--;
- session = (Session) recycled.get(index);
- recycled.remove(index);
- } while ( index > 0 && (session instanceof ReplicatedSession));
- }
- }//synchronized
-
- //set the current manager
- if (session != null)
- session.setManager(this);
- else
- session = new ReplicatedSession(this);
+ Session session = new ReplicatedSession(this);
// Initialize the properties of the new session and return it
session.setNew(true);
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: cvs commit: jakarta-tomcat-catalina/modules/cluster/src/share/org/apache/catalina/cluster/session
SimpleTcpReplicationManager.java
Posted by Remy Maucherat <re...@apache.org>.
Costin Manolache wrote:
> I remember making a change in 5.0 jasper to make it configurable on a
> per-page basis.
That's a good feature, and I've been using it without problems. Since
it's dynamic, I couldn't verify just yet that it did what it advertised,
though ;-)
Remy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: cvs commit: jakarta-tomcat-catalina/modules/cluster/src/share/org/apache/catalina/cluster/session SimpleTcpReplicationManager.java
Posted by Costin Manolache <cm...@yahoo.com>.
I remember making a change in 5.0 jasper to make it configurable on a
per-page basis.
I agree that tag pooling has some cases where it is less efficient, but
there are also many pages where it is much better.
Costin
Bill Barker wrote:
>
> ----- Original Message -----
> From: "Remy Maucherat" <re...@apache.org>
> To: "Tomcat Developers List" <to...@jakarta.apache.org>
> Sent: Tuesday, July 08, 2003 12:11 AM
> Subject: Re: cvs commit:
>
jakarta-tomcat-catalina/modules/cluster/src/share/org/apache/catalina/cluste
> r/session SimpleTcpReplicationManager.java
>
>
>> 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.
>
> Just not in my use case (where it s*cks :-). This is actually the last
> thing that I have to modify the source in 4.1.25 to get it to work-for-me.
> If it was actually configurable for a <jsp-page> servlet (without copying
> all of the JspServlet's init-params into my servlets, and rendering myapp
> hopelessly unportable), I'd be happy as well.
>
> Needless to say, I haven't figured out a way to do this in the Catalina
> API, or I'd have done it long ago ;-).
>
>>
>> Remy
>>
>>
>>
>> ---------------------------------------------------------------------
>> 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
Re: cvs commit: jakarta-tomcat-catalina/modules/cluster/src/share/org/apache/catalina/cluster/session SimpleTcpReplicationManager.java
Posted by Bill Barker <wb...@wilshire.com>.
----- Original Message -----
From: "Remy Maucherat" <re...@apache.org>
To: "Tomcat Developers List" <to...@jakarta.apache.org>
Sent: Tuesday, July 08, 2003 12:11 AM
Subject: Re: cvs commit:
jakarta-tomcat-catalina/modules/cluster/src/share/org/apache/catalina/cluste
r/session SimpleTcpReplicationManager.java
> 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.
Just not in my use case (where it s*cks :-). This is actually the last
thing that I have to modify the source in 4.1.25 to get it to work-for-me.
If it was actually configurable for a <jsp-page> servlet (without copying
all of the JspServlet's init-params into my servlets, and rendering myapp
hopelessly unportable), I'd be happy as well.
Needless to say, I haven't figured out a way to do this in the Catalina API,
or I'd have done it long ago ;-).
>
> Remy
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
Re: Object pooling performance
Posted by Peter Lin <tc...@yahoo.com>.
Costin Manolache <cm...@yahoo.com> wrote:
On the other hand, I've seen pages where JSP tag pooling was worse.
That's why I think per page customization, and supporting per-thread pooling
are very important. This is a "fine-tune" operation for pages that are
frequently accessed, not a "one size fit all" problem.
Costin
I've also seen this happen for pages that only have a couple tags. from my own benchmarks, pages with less than 40 tags are better off not using tag pooling. the per page fine-tuning is a nice way to maximize performance :)
peter
---------------------------------
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
Re: Object pooling performance
Posted by Costin Manolache <cm...@yahoo.com>.
Glenn Nielsen wrote:
> 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.
And depending on the recyling mechanism :-)
Using per-thread objects ( like tomcat request objects ) doesn't require
sync, and I can't see any way creating/gc a new object by the VM could be
faster.
Pools that use sync may be slower than modern VMs which use multiple
memory areas to allocate objects ( or per thread ) - since the VM avoids
the sync. A smarter object pool that would use buckets of objects or
per thread data would again be faster than VM.
The think to remember is that "one object" doesn't matter too much, but if
you have big arrays or other data structures that could be reused - more
likely even the most stupid pool will beat the VM.
> 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.
On the other hand, I've seen pages where JSP tag pooling was worse.
That's why I think per page customization, and supporting per-thread pooling
are very important. This is a "fine-tune" operation for pages that are
frequently accessed, not a "one size fit all" problem.
Costin
>
> 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
Re: Object pooling performance
Posted by Remy Maucherat <re...@apache.org>.
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
Re: Object pooling performance
Posted by Remy Maucherat <re...@apache.org>.
Peter Lin wrote:
> I second remy's summary. from first hand experience with JSP with 200 tags,
> tag pooling provide significant performance improvement. From what I saw in
> OptimizeIt, with jasper1 and 200+ tags per page, garbage collection was happening
> frequently and full GC was occuring way too often.
>
> with tag pooling in jasper2, that changed the GC behavior and resulted in significant
> improvement with 5 or more concurrent requests.
Also, thread local pools from TC 5 should help solve syncing issues. Of
course, it would be hard to do a straight comparison given that TC 5 has
a significantly lower overhead than TC 4.1.
Maybe using the Jasper 2 binaries from TC 4.1 to replace the ones from
TC 5 could yield a fair comparison.
Remy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Object pooling performance
Posted by Peter Lin <tc...@yahoo.com>.
I second remy's summary. from first hand experience with JSP with 200 tags, tag pooling provide significant performance improvement. From what I saw in OptimizeIt, with jasper1 and 200+ tags per page, garbage collection was happening frequently and full GC was occuring way too often.
with tag pooling in jasper2, that changed the GC behavior and resulted in significant improvement with 5 or more concurrent requests.
peter lin
Glenn Nielsen <gl...@mail.more.net> wrote:
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
---------------------------------
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
Object pooling performance
Posted by Glenn Nielsen <gl...@mail.more.net>.
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
Re: cvs commit: jakarta-tomcat-catalina/modules/cluster/src/share/org/apache/catalina/cluster/session
SimpleTcpReplicationManager.java
Posted by Remy Maucherat <re...@apache.org>.
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.
Remy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: cvs commit: jakarta-tomcat-catalina/modules/cluster/src/share/org/apache/catalina/cluster/session SimpleTcpReplicationManager.java
Posted by Bill Barker <wb...@wilshire.com>.
> - //I personally believe the VM does a much better job pooling
object instances
> - //than the synchronized penalty gives us
Now, if we could only convince the Jasper developers of this ... ;-).