Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Developers List" <tomcat-dev@jakarta.apache.org>
To: tomcat-dev@jakarta.apache.org
Path: not-for-mail
From: Costin Manolache <cmanolache@yahoo.com>
Subject: Re: Tag reuse performance [Was: Re: DO NOT REPLY [Bug 16001]  -
 Tag.release() not invoked]
Date: Mon, 20 Jan 2003 13:31:32 -0800
Lines: 134
Message-ID: <b0hq2m$ft2$1@main.gmane.org>
References: <b0fvk6$vcs$1@main.gmane.org>
 <20030120185613.15977.qmail@web20210.mail.yahoo.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7Bit
User-Agent: KNode/0.7.1
Sender: news <news@main.gmane.org>

Peter Lin wrote:

> 
>  
> 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.


Is this based on the current tag pool implementation in jasper2 ?
Because it is pretty clear that the tag pool has few problems. 

I would say the nature of the tags will also have a big impact. If your
tag is very simple - you'll probably get some "small" benefits under load
( 20..30% ?). If the tag uses internal data structures, buffers, etc - 
it's very likely you'll see more ( since creating each tag instance will
also create the additional hashtable, StringBuffers, etc ).

I would bet that with complex tags that are specifically written to take 
advantage of the recycling you would see at least 2x better performance ( 
with a good sync-free and large enough tag pool ). If your tag is using 
any buffers or complex/expensive data structures that can be recycled - 
you'll save a lot. 

I don't think the number of tags in a page is too important - even if you
have 1 complex tag - with 100 concurent users - you should see a difference.

In an ideal world, all "core" tags would be recyclable and garbage-free - 
that may allow them to run at comparable speed with a hard-coded page.


Costin


>  
> peter lin
>  
>  Costin Manolache <cmanolache@yahoo.com> 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


--
To unsubscribe, e-mail:   <mailto:tomcat-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:tomcat-dev-help@jakarta.apache.org>