You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by ma...@apache.org on 2010/11/17 14:05:20 UTC
svn commit: r1036021 -
/tomcat/trunk/test/org/apache/catalina/session/Benchmarks.java
Author: markt
Date: Wed Nov 17 13:05:20 2010
New Revision: 1036021
URL: http://svn.apache.org/viewvc?rev=1036021&view=rev
Log:
Increase length of tests to
a) reduce impact of start-up overhead
b) make it easier to profile
Modified:
tomcat/trunk/test/org/apache/catalina/session/Benchmarks.java
Modified: tomcat/trunk/test/org/apache/catalina/session/Benchmarks.java
URL: http://svn.apache.org/viewvc/tomcat/trunk/test/org/apache/catalina/session/Benchmarks.java?rev=1036021&r1=1036020&r2=1036021&view=diff
==============================================================================
--- tomcat/trunk/test/org/apache/catalina/session/Benchmarks.java (original)
+++ tomcat/trunk/test/org/apache/catalina/session/Benchmarks.java Wed Nov 17 13:05:20 2010
@@ -31,10 +31,10 @@ public class Benchmarks extends TestCase
/*
* Results on markt's 4-core Windows dev box
- * 1 thread - ~300ms
- * 2 threads - ~330ms
- * 4 threads - ~480ms
- * 16 threads - ~2,200ms
+ * 1 thread - ~1,900ms
+ * 2 threads - ~3,300ms
+ * 4 threads - ~4,800ms
+ * 16 threads - ~21,000ms
*
* Results on markt's 2-core OSX dev box (out of date)
* 1 thread - ~720ms
@@ -43,16 +43,16 @@ public class Benchmarks extends TestCase
* 16 threads - ~12,700ms
*/
public void testManagerBaseGenerateSessionId() {
- doTestManagerBaseGenerateSessionId(1, 100000);
- doTestManagerBaseGenerateSessionId(1, 100000);
- doTestManagerBaseGenerateSessionId(1, 100000);
- doTestManagerBaseGenerateSessionId(2, 100000);
- doTestManagerBaseGenerateSessionId(2, 100000);
- doTestManagerBaseGenerateSessionId(2, 100000);
- doTestManagerBaseGenerateSessionId(4, 100000);
- doTestManagerBaseGenerateSessionId(4, 100000);
- doTestManagerBaseGenerateSessionId(4, 100000);
- doTestManagerBaseGenerateSessionId(16, 100000);
+ doTestManagerBaseGenerateSessionId(1, 1000000);
+ doTestManagerBaseGenerateSessionId(1, 1000000);
+ doTestManagerBaseGenerateSessionId(1, 1000000);
+ doTestManagerBaseGenerateSessionId(2, 1000000);
+ doTestManagerBaseGenerateSessionId(2, 1000000);
+ doTestManagerBaseGenerateSessionId(2, 1000000);
+ doTestManagerBaseGenerateSessionId(4, 1000000);
+ doTestManagerBaseGenerateSessionId(4, 1000000);
+ doTestManagerBaseGenerateSessionId(4, 1000000);
+ doTestManagerBaseGenerateSessionId(16, 1000000);
}
@@ -114,10 +114,10 @@ public class Benchmarks extends TestCase
/*
* Results on markt's 4-core Windows dev box
- * 1 thread - ~625ms
- * 2 threads - ~690ms
- * 4 threads - ~1,100ms
- * 16 threads - ~4,300ms
+ * 1 thread - ~4,600ms
+ * 2 threads - ~6,700ms
+ * 4 threads - ~10,400ms
+ * 16 threads - ~43,800ms
*
* Results on markt's 2-core OSX dev box (out of date)
* 1 thread - ~1,500ms
@@ -126,10 +126,10 @@ public class Benchmarks extends TestCase
* 16 threads - ~18,600ms
*/
public void testManagerBaseCreateSession() {
- doTestManagerBaseCreateSession(1, 100000);
- doTestManagerBaseCreateSession(2, 100000);
- doTestManagerBaseCreateSession(4, 100000);
- doTestManagerBaseCreateSession(16, 100000);
+ doTestManagerBaseCreateSession(1, 1000000);
+ doTestManagerBaseCreateSession(2, 1000000);
+ doTestManagerBaseCreateSession(4, 1000000);
+ doTestManagerBaseCreateSession(16, 1000000);
}
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: svn commit: r1036021 - /tomcat/trunk/test/org/apache/catalina/session/Benchmarks.java
Posted by Mark Thomas <ma...@apache.org>.
On 17/11/2010 13:35, Mark Thomas wrote:
> On 17/11/2010 13:05, markt@apache.org wrote:
>> Author: markt
>> Date: Wed Nov 17 13:05:20 2010
>> New Revision: 1036021
>>
>> URL: http://svn.apache.org/viewvc?rev=1036021&view=rev
>> Log:
>> Increase length of tests to
>> a) reduce impact of start-up overhead
>> b) make it easier to profile
>
> Looks like the next bottleneck is in StandardSession.expire(boolean) due
> to this code:
While this is the bottleneck if you just look at session
creation/destruction, this is down in the noise in the overall
processing chain. I'll leave this code as is for now.
> - 'current' session creation rate
> - 'current' session expiration rate
I will still look at adding these metrics and I'll use the performance
metrics to ensure there is no noticeable performance impact.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: svn commit: r1036021 - /tomcat/trunk/test/org/apache/catalina/session/Benchmarks.java
Posted by Mark Thomas <ma...@apache.org>.
On 17/11/2010 19:49, Konstantin Kolinko wrote:
> My impression looking on the above cited code of StandardSession is
> that all that arithmetics should be done inside the manager.
>
> Then the manager can be optimized how to store it.
+1, although it is slightly complicated by the PersistentManager that
can call Manager.remove() when the session hasn't expired. Also, I don't
think this is a bottleneck we need to worry about too much right now.
> E.g., unless someone calls getSessionAverageAliveTime() the value of
> average = (int) (((average * (numExpired-1)) + timeAlive)/numExpired);
> is not needed.
I think it is due to the way the average is maintained. It needs to be
updated on every expiration. I'll see if a better option emerges when I
add the rate of creatation/destruction stats.
> Also that call can be moved out of synchronized(this).
I don't think so, given the way it is currently calculated. Again, I'll
see if a better solution emerges when I add the other stats.
Cheers,
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: svn commit: r1036021 - /tomcat/trunk/test/org/apache/catalina/session/Benchmarks.java
Posted by Konstantin Kolinko <kn...@gmail.com>.
2010/11/17 Mark Thomas <ma...@apache.org>:
> On 17/11/2010 13:05, markt@apache.org wrote:
>> Author: markt
>> Date: Wed Nov 17 13:05:20 2010
>> New Revision: 1036021
>>
>> URL: http://svn.apache.org/viewvc?rev=1036021&view=rev
>> Log:
>> Increase length of tests to
>> a) reduce impact of start-up overhead
>> b) make it easier to profile
>
> Looks like the next bottleneck is in StandardSession.expire(boolean) due
> to this code:
>
> /*
> * Compute how long this session has been alive, and update
> * session manager's related properties accordingly
> */
> long timeNow = System.currentTimeMillis();
> int timeAlive = (int) ((timeNow - creationTime)/1000);
> synchronized (manager) {
> if (timeAlive > manager.getSessionMaxAliveTime()) {
> manager.setSessionMaxAliveTime(timeAlive);
> }
> long numExpired = manager.getExpiredSessions();
> numExpired++;
> manager.setExpiredSessions(numExpired);
> int average = manager.getSessionAverageAliveTime();
> average = (int) (((average * (numExpired-1)) +
> timeAlive)/numExpired);
> manager.setSessionAverageAliveTime(average);
> }
>
> Having an exact value for that metric (that I doubt most users even know
> about let alone use) is very expensive. I'm going to look at creation on
> OSX for a little while but I plan to come back to this afterwards. I am
> thinking something along the lines of queues for the last 100 or so
> values of the following:
> - session creation time
> - session expiration time
> - session alive time
> from which metrics such as:
> - 'current' average alive time
> - 'current' session creation rate
> - 'current' session expiration rate
> can be calculated when required. The calculation will probably be
> expensive but better than than expensive operations on every session
> expiration.
>
My impression looking on the above cited code of StandardSession is
that all that arithmetics should be done inside the manager.
Then the manager can be optimized how to store it.
E.g., unless someone calls getSessionAverageAliveTime() the value of
average = (int) (((average * (numExpired-1)) + timeAlive)/numExpired);
is not needed.
Also that call can be moved out of synchronized(this).
Best regards,
Konstantin Kolinko
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: svn commit: r1036021 - /tomcat/trunk/test/org/apache/catalina/session/Benchmarks.java
Posted by Mark Thomas <ma...@apache.org>.
On 17/11/2010 13:05, markt@apache.org wrote:
> Author: markt
> Date: Wed Nov 17 13:05:20 2010
> New Revision: 1036021
>
> URL: http://svn.apache.org/viewvc?rev=1036021&view=rev
> Log:
> Increase length of tests to
> a) reduce impact of start-up overhead
> b) make it easier to profile
Looks like the next bottleneck is in StandardSession.expire(boolean) due
to this code:
/*
* Compute how long this session has been alive, and update
* session manager's related properties accordingly
*/
long timeNow = System.currentTimeMillis();
int timeAlive = (int) ((timeNow - creationTime)/1000);
synchronized (manager) {
if (timeAlive > manager.getSessionMaxAliveTime()) {
manager.setSessionMaxAliveTime(timeAlive);
}
long numExpired = manager.getExpiredSessions();
numExpired++;
manager.setExpiredSessions(numExpired);
int average = manager.getSessionAverageAliveTime();
average = (int) (((average * (numExpired-1)) +
timeAlive)/numExpired);
manager.setSessionAverageAliveTime(average);
}
Having an exact value for that metric (that I doubt most users even know
about let alone use) is very expensive. I'm going to look at creation on
OSX for a little while but I plan to come back to this afterwards. I am
thinking something along the lines of queues for the last 100 or so
values of the following:
- session creation time
- session expiration time
- session alive time
from which metrics such as:
- 'current' average alive time
- 'current' session creation rate
- 'current' session expiration rate
can be calculated when required. The calculation will probably be
expensive but better than than expensive operations on every session
expiration.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org