: Tag Pooling ( was: Re: DO NOT REPLY [Bug 16001] -
Tag.release()
not invoked
Taking Glenn's post out of thread:
Glenn Nielsen wrote:
Per JSP Page (current)
--
The current tag pool manages one or more pools of tags on a per JSP
page basis
Costin Manolache wrote:
Hans Bergsten wrote:
Costin Manolache wrote:
[...]
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.
I think it's more important to implement open coding of JSTL, i.e.
Costin Manolache wrote:
Taking Glenn's post out of thread:
Glenn Nielsen wrote:
Per JSP Page (current)
--
The current tag pool manages one or more pools of tags on a per JSP
page basis. With a synchronized method call for each get/reuse pair
for a TagHandler used in the
Hans Bergsten wrote:
Tim Moore wrote:
This bug seems to be submitted several times a week. Maybe an FAQ would
be in order? (or FOB -- frequently opened bugs haha)
Then again, if people don't search the bug database before submitting a
new one, then I guess they can't be expected to read the
Johan Åbrandt wrote:
Hans Bergsten wrote:
Tim Moore wrote:
This bug seems to be submitted several times a week. Maybe an FAQ would
be in order? (or FOB -- frequently opened bugs haha)
Then again, if people don't search the bug database before submitting a
new one, then I guess they can't be
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
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
these were all JSTL tags. Back when I ran the tests, I posted some of the results. I
did tests that were synthetic, ie out 100 JSTL out tags in one page. Others were
based on an actual page layout with lots of markup logic that use jstl c:choose in
conjunction with jslt xml tags.
the
Taking Glenn's post out of thread:
Glenn Nielsen wrote:
Per JSP Page (current)
--
The current tag pool manages one or more pools of tags on a per JSP
page basis. With a synchronized method call for each get/reuse pair
for a TagHandler used in the page. That page could
Costin Manolache wrote:
[...]
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.
I think it's more important to implement open coding of JSTL, i.e.
generate if and for statement instead of using c:if and
Hans Bergsten wrote:
Costin Manolache wrote:
[...]
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.
I think it's more important to implement open coding of JSTL, i.e.
generate if and for
Hans Bergsten wrote:
Johan Åbrandt wrote:
Hans Bergsten wrote:
Tim Moore wrote:
This bug seems to be submitted several times a week. Maybe an FAQ
would
be in order? (or FOB -- frequently opened bugs haha)
Then again, if people don't search the bug database before submitting a
new one,
Hans Bergsten wrote:
Without pooling With pooling Reuse w/o overhead
-
5 threads
Avg.: 330 ms349 ms N/A
Rate:15.2/sec 13.6/sec N/A
20
Interesting. Your test JSP page looks like a valid test.
There is no data about GC in your tests, of course GC can happen at any time.
I would be interested in seeing the tests run with -Xincgc and -Xverbose:gc.
Then run a high enough volume of tests that a Full GC gets triggered a dozen
times
Glenn Nielsen wrote:
Interesting. Your test JSP page looks like a valid test.
Good.
There is no data about GC in your tests, of course GC can happen at any
time.
I would be interested in seeing the tests run with -Xincgc and
-Xverbose:gc.
Then run a high enough volume of tests that a Full
Costin Manolache wrote:
Hans Bergsten wrote:
Without pooling With pooling Reuse w/o overhead
-
5 threads
Avg.: 330 ms349 ms N/A
Rate:15.2/sec 13.6/sec
Hans Bergsten wrote:
Costin Manolache wrote:
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
Hans Bergsten wrote:
Without pooling With pooling Reuse w/o overhead
-
5 threads
Avg.: 330 ms349 ms N/A
Rate:15.2/sec 13.6/sec N/A
20 threads
Bill Barker wrote:
I saw just the opposite. Jasper2 with tag-pooling was a real dog (the time
spent in synchronized methods to maintain the pool completely swamped any
benefit from GC). After patching my copy to make don't-tag-pool the default
(since there isn't any way to do this in the config
- Original Message -
From: Remy Maucherat [EMAIL PROTECTED]
To: Tomcat Developers List [EMAIL PROTECTED]
Sent: Saturday, January 18, 2003 12:36 AM
Subject: Re: DO NOT REPLY [Bug 16001] - Tag.release() not invoked
Bill Barker wrote:
I saw just the opposite. Jasper2 with tag-pooling
Bill Barker wrote:
Yeah, well, almost all of my JSP pages are defined by:
servlet
servlet-namesomename/servlet-name
jsp-page/somepath/somepage.jsp/jsp-page
/servlet
And I can assure you that the params for JspServlet don't work at all
(unless I take the totally brain-dead path of including
I patched jasper2 and tagpool to synchronize only at begin/end of the jsp site
= 2 syncs per request
Torsten Fohrer
On Saturday 18 January 2003 10:24, you wrote:
Bill Barker wrote:
Yeah, well, almost all of my JSP pages are defined by:
servlet
servlet-namesomename/servlet-name
Bill Barker wrote:
If tag-pooling works for you, I'm happy for you. The current
implementation
doesn't work for me big time. However, I'm very interested in Costin's
claim that it can be done thread-local.
One quick question ( looking at generated code ) - why is the TP limited
to 5
Costin Manolache wrote:
Bill Barker wrote:
If tag-pooling works for you, I'm happy for you. The current
implementation
doesn't work for me big time. However, I'm very interested in Costin's
claim that it can be done thread-local.
One quick question ( looking at generated code ) - why is
one questions? can jasper not use a simply synchronized block on the jsp
instance, getting 1 tag instance/class/declaration and stores it somewhere,
as a example in the pageContext/local variable, and synchronize later in the
finally block and puts back the tag instances.
Torsten
On Saturday
I agree that the currnet Jasper tag pooling could be improved.
Per JSP Page (current)
--
The current tag pool manages one or more pools of tags on a per JSP
page basis. With a synchronized method call for each get/reuse pair
for a TagHandler used in the page. That page could
Remy Maucherat wrote:
If tag-pooling works for you, I'm happy for you. The current
implementation
doesn't work for me big time. However, I'm very interested in Costin's
claim that it can be done thread-local.
One quick question ( looking at generated code ) - why is the TP limited
to 5
please, correct my if i be wrong.
On Saturday 18 January 2003 22:56, you wrote:
I agree that the currnet Jasper tag pooling could be improved.
Per JSP Page (current)
--
The current tag pool manages one or more pools of tags on a per JSP
page basis. With a
Hans Bergsten wrote:
Costin Manolache wrote:
[...]
Wow. I would be _very_ curious to see those benchmarks and the modern
JVM that was used.
All my tests ( including JDK1.4, IBM vms, GCJ ) show that reusing is well
worth the trouble - at least if you have 100s of requests per second
( it is not
Martin Algesten wrote:
Remy,
once again we agree :)
Lol, I guess. After the 100th time this bug is being reopened, I'm
getting pissed ;-)
Remy
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Floor / Washington, DC 20036
Phone 202-463-4860 ext. 258 / Fax 202-463-4863
-Original Message-
From: Remy Maucherat [mailto:[EMAIL PROTECTED]]
Sent: Friday, January 17, 2003 10:58 AM
To: Tomcat Developers List
Subject: Re: DO NOT REPLY [Bug 16001] - Tag.release() not invoked
Martin
-Original Message-
From: Hans Bergsten [mailto:[EMAIL PROTECTED]]
Sent: Friday, January 17, 2003 1:37 PM
To: Tomcat Developers List
Subject: Re: DO NOT REPLY [Bug 16001] - Tag.release() not invoked
Tim Moore wrote:
This bug seems to be submitted several times a week. Maybe
Tim Moore wrote:
[...]
I agree that the current behavior of release should not change. There
are important uses for long-term state that we shouldn't throw away just
because of some confusion.
Right.
But what do you think about the idea of adding a new method? My
thinking is that if there
Remy,
once again we agree :)
M
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: 17 January 2003 14:19
To: [EMAIL PROTECTED]
Subject: DO NOT REPLY [Bug 16001] - Tag.release() not invoked
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED
Hans Bergsten wrote:
evaluation all in one place. To make things even easier, these tag
handlers can _not_ be reused at all. Benchmarks with modern JVMs show
that the gain from reuse is not worth all the trouble. So, for new
tags we recommend using the SimpleTag API which takes care of the
-Original Message-
From: Costin Manolache [mailto:[EMAIL PROTECTED]]
Sent: Friday, January 17, 2003 5:49 PM
To: [EMAIL PROTECTED]
Subject: Re: DO NOT REPLY [Bug 16001] - Tag.release() not invoked
Hans Bergsten wrote:
evaluation all in one place. To make things even easier
Costin Manolache wrote:
Hans Bergsten wrote:
evaluation all in one place. To make things even easier, these tag
handlers can _not_ be reused at all. Benchmarks with modern JVMs show
that the gain from reuse is not worth all the trouble. So, for new
tags we recommend using the SimpleTag API
Tim Moore wrote:
[...]
I thought the benefit of Tag.release and pooling was that I could create
a tag that does something expensive at init time (acquire a DB
connection, read a file, whatever) and reuse those resources until
released. Maybe that's a bad practice? But then what's the advantage
Costin Manolache wrote:
Hans Bergsten wrote:
evaluation all in one place. To make things even easier, these tag
handlers can _not_ be reused at all. Benchmarks with modern JVMs show
that the gain from reuse is not worth all the trouble. So, for new
tags we recommend using the SimpleTag API
- Original Message -
From: Glenn Nielsen [EMAIL PROTECTED]
To: Tomcat Developers List [EMAIL PROTECTED]
Sent: Friday, January 17, 2003 7:04 PM
Subject: Re: DO NOT REPLY [Bug 16001] - Tag.release() not invoked
Costin Manolache wrote:
Hans Bergsten wrote:
evaluation all in one
Bill Barker wrote:
I saw a significant, measureable improvement in performance when I
upgraded
our production systems to Jasper 2 with tag pooling from Jasper 1
without. CPU load on the production server dropped around 30%, request
latency was
reduced significantly, etc. The app server
41 matches
Mail list logo
