I haven't read all the posts on this discussion, but here's some facts from personal 
observations.
for pages with only a few tags, ie less than 30, tag pooling doesn't help.  On the 
otherhand, if your page has 100+ tags, it improves performance. Some of the pages I 
benchmarked with had about 135 tags. In those situations, I saw a 20-50% improvement. 
I would argue that sites that don't have a lot of load should simply turn off tag 
pooling.  Site that use tags extensively and get 1millions page views a day, will gain 
significantly from tag pooling.
 
peter lin
 
 Costin Manolache <[EMAIL PROTECTED]> wrote: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. 

Costin




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



---------------------------------
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now

Reply via email to