tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Costin Manolache <>
Subject Re: Tag reuse performance [Was: Re: DO NOT REPLY [Bug 16001] - Tag.release() not invoked]
Date Mon, 20 Jan 2003 04:55:08 GMT
Hans Bergsten wrote:

>>>             Without pooling  With pooling  Reuse w/o overhead
>>>5 threads
>>>   Avg.:              330 ms        349 ms                 N/A
>>>   Rate:            15.2/sec      13.6/sec                 N/A
>>>20 threads
>>>   Avg.:            1,752 ms      1,446 ms            1,265 ms
>>>   Rate:            12.1/sec      13.6/sec            14.7/sec
>>>To me, this indicates that if you can avoid _all_ reuse overhead,
>>>there's some performace to be gained from reuse but not much. With the
>>>>From 1.2s to 1.7s there is about 35% difference. I would call this
>> quite significant. Even between 1.4 and 1.7 - you have 20%. Try to
>> increase the thread count to 100 - and you'll see this going up.
>> The difference ( 0.5s ) is probably 2-3 times the response time of
>> apache for a static page. And most users will feel it.
> I agree that in percentage, the difference is somewhat significant,
> but don't make too much out of the real value. My test server is not
> representative of the type of hardware you would use for a site with
> this type of load. On hardware suitable for the task, the difference in

And the test page is not representative of the type of pages that will
run on a real site.  I know that.

All we can measure with relative accuracy is the overhead of the 
container/jsp implementation - at least in relative terms. 
Take as the reference the time ( or RPS ) for Apache to serve the same
output as a static page. Or the time a servlet will take to generate
the same output. Run your tests with 5, 20, 100 RPS ( and "ab" may be
a better driver ). Compare the results - and most likely a production
server will see similar ratios.

I'll try to find some time ( next week - I hope ) and run the same 
tests with the "no sync" pool.

> the real values will likely be a lot smaller, and IMHO, insignificant.
> But please, let's not start a long debate about what's significant or
> not (that depends on too many factors). All I'm trying to show with
> these simple tests is that for pooling to really make a difference at
> all, you need to avoid all overhead, which may be very hard, and that
> the overhead with current pooling seems to eat all potential gain.

Well - it shows pretty clearly that the _current_ implementation
of thread pool is broken. Even if we don't take sync into account, the pool
has a 5 object limit - what else could you expect ??

> I ran 10,000 requests for each test case after a manual warm up (just a
> few requests to give the JIT a chance to kick in). If I rerun the tests
> to capture GC data (as Glen was asking for), I can run a longer warm-up
> as well. I didn't record the max values, but IIRC they were around 100
> sec in all cases.

The 1.4 JIT takes some time to kick in, if you run batches of 1000 requests
you'll see the time keeps improving. I would do at leat 5000 request to
warm up the jit.

>> This is a very good start, thanks for bringing this up.
> I hope it at least gives us a better idea about what types of gains
> we can realistically expect from tag handler reuse.

Most of the improvements in coyote ( or in 3.3 over 3.2 ) are due to 
object reuse. It is possible that tag handlers are different and 
the other overheads will obscure any benefit ( at least under low load ),
but I can bet that under heavy load recycling will be very significant, if 
done correctly. 


To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message