You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Kevin Burton <bu...@rojo.com> on 2005/05/28 07:02:12 UTC
The amazingly slow performance of JSP (profiler results)
I've been tuning our application trying to get the maximum performance
out if the system as possible.
I've been throwing the system at jprofiler and allowing it to tell me
where to optimized.
In short Tomcat is slower than our DB, filesystem,. network and all
other systems by about 4x.
I've been able to shave some page load time off by some but not enough.
The problem I'm starting to see is that we just have a large number of
c:set and c:if constructs (and so forth) within loops. These loops then
get executed 5 times and next thing you know it you have 50k taglib calls.
The problem comes when you look at the source:
Let's say you start with:
> <c:set var="foo" value="bar"/>
This nice little elegant piece of code gets expanded to:
> private boolean _jspx_meth_c_set_0(PageContext _jspx_page_context)
> throws Throwable {
> PageContext pageContext = _jspx_page_context;
> JspWriter out = _jspx_page_context.getOut();
> // c:set
> org.apache.taglibs.standard.tag.rt.core.SetTag _jspx_th_c_set_0 =
> (org.apache.taglibs.standard.tag.rt.core.SetTag)
> _jspx_tagPool_c_set_var_value_nobody.get(org.apache.taglibs.standard.tag.rt.core.SetTag.class);
> _jspx_th_c_set_0.setPageContext(_jspx_page_context);
> _jspx_th_c_set_0.setParent(null);
> _jspx_th_c_set_0.setVar("foo");
> _jspx_th_c_set_0.setValue(new String("bar"));
> int _jspx_eval_c_set_0 = _jspx_th_c_set_0.doStartTag();
> if (_jspx_th_c_set_0.doEndTag() ==
> javax.servlet.jsp.tagext.Tag.SKIP_PAGE)
> return true;
> _jspx_tagPool_c_set_var_value_nobody.reuse(_jspx_th_c_set_0);
> return false;
> }
Which explains why JSP alone is so amazingly slow!
I did a comparison of the page performance here and it was 15x slower than just using Java. So the same "set" operation in Java was 15x faster.
... so in short ... does anyone have any way to speed this up?
The other thing I noticed is that EL is evaluated at runtime (which has to be parsed) and sometimes uses reflections. Can anyone shed any more light on this and hopefully provide some performance optimization suggestions?
Kevin
--
Use Rojo (RSS/Atom aggregator)! - visit http://rojo.com.
See irc.freenode.net #rojo if you want to chat.
Rojo is Hiring! - http://www.rojonetworks.com/JobsAtRojo.html
Kevin A. Burton, Location - San Francisco, CA
AIM/YIM - sfburtonator, Web - http://peerfear.org/
GPG fingerprint: 5FB2 F3E2 760E 70A8 6174 D393 E84D 8D04 99F1 4412
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: The amazingly slow performance of JSP (profiler results)
Posted by Kevin Burton <bu...@rojo.com>.
Dakota Jack wrote:
>You have to be and are comparing apples and oranges, Kevin,
>
Perhaps... but my point was that JSP 2.0 doesn't HAVE to be this slow! :)
>because
>JSP *is* Java. DOH! It cannot run slower than what it is.
>
No.. it could run slower... I'm sure the Tomcat developers will find a
way ;)
>You
>probably are comparing just running a Java method like setFoo(String
>foo) { this.foo = foo; } where the parameter foo has the value "bar".
>But, this is really misleading. The "simple" code you write with
><c:set var="foo" value="bar"/> in fact is just as complex as what you
>see and have provided in your email. So, if you want to compare, you
>have to do all that the code you see as *ugly* does.
>
No ... of course not! For example a JSP 1.x scriptlet would NOT be
anywhere near as slow!
>If you don't
>want to do all that, don't. But, that is not a problem with JSP and
>JSP is not a dog if used properly.
>
Ha... so what's properly? Don't use c:set? Don't use c:if ?...
>That's all I have to say about
>that.
>
>
OK forest :)
Kevin
--
Use Rojo (RSS/Atom aggregator)! - visit http://rojo.com.
See irc.freenode.net #rojo if you want to chat.
Rojo is Hiring! - http://www.rojonetworks.com/JobsAtRojo.html
Kevin A. Burton, Location - San Francisco, CA
AIM/YIM - sfburtonator, Web - http://peerfear.org/
GPG fingerprint: 5FB2 F3E2 760E 70A8 6174 D393 E84D 8D04 99F1 4412
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: The amazingly slow performance of JSP (profiler results)
Posted by Dakota Jack <da...@gmail.com>.
You have to be and are comparing apples and oranges, Kevin, because
JSP *is* Java. DOH! It cannot run slower than what it is. You
probably are comparing just running a Java method like setFoo(String
foo) { this.foo = foo; } where the parameter foo has the value "bar".
But, this is really misleading. The "simple" code you write with
<c:set var="foo" value="bar"/> in fact is just as complex as what you
see and have provided in your email. So, if you want to compare, you
have to do all that the code you see as *ugly* does. If you don't
want to do all that, don't. But, that is not a problem with JSP and
JSP is not a dog if used properly. That's all I have to say about
that.
On 5/27/05, Kevin Burton <bu...@rojo.com> wrote:
> I've been tuning our application trying to get the maximum performance
> out if the system as possible.
>
> I've been throwing the system at jprofiler and allowing it to tell me
> where to optimized.
>
> In short Tomcat is slower than our DB, filesystem,. network and all
> other systems by about 4x.
>
> I've been able to shave some page load time off by some but not enough.
>
> The problem I'm starting to see is that we just have a large number of
> c:set and c:if constructs (and so forth) within loops. These loops then
> get executed 5 times and next thing you know it you have 50k taglib calls.
>
> The problem comes when you look at the source:
>
> Let's say you start with:
>
> > <c:set var="foo" value="bar"/>
>
> This nice little elegant piece of code gets expanded to:
>
> > private boolean _jspx_meth_c_set_0(PageContext _jspx_page_context)
> > throws Throwable {
> > PageContext pageContext = _jspx_page_context;
> > JspWriter out = _jspx_page_context.getOut();
> > // c:set
> > org.apache.taglibs.standard.tag.rt.core.SetTag _jspx_th_c_set_0 =
> > (org.apache.taglibs.standard.tag.rt.core.SetTag)
> > _jspx_tagPool_c_set_var_value_nobody.get(org.apache.taglibs.standard.tag.rt.core.SetTag.class);
> > _jspx_th_c_set_0.setPageContext(_jspx_page_context);
> > _jspx_th_c_set_0.setParent(null);
> > _jspx_th_c_set_0.setVar("foo");
> > _jspx_th_c_set_0.setValue(new String("bar"));
> > int _jspx_eval_c_set_0 = _jspx_th_c_set_0.doStartTag();
> > if (_jspx_th_c_set_0.doEndTag() ==
> > javax.servlet.jsp.tagext.Tag.SKIP_PAGE)
> > return true;
> > _jspx_tagPool_c_set_var_value_nobody.reuse(_jspx_th_c_set_0);
> > return false;
> > }
>
> Which explains why JSP alone is so amazingly slow!
>
>
> I did a comparison of the page performance here and it was 15x slower than just using Java. So the same "set" operation in Java was 15x faster.
>
> ... so in short ... does anyone have any way to speed this up?
>
> The other thing I noticed is that EL is evaluated at runtime (which has to be parsed) and sometimes uses reflections. Can anyone shed any more light on this and hopefully provide some performance optimization suggestions?
>
> Kevin
>
> --
>
>
> Use Rojo (RSS/Atom aggregator)! - visit http://rojo.com.
> See irc.freenode.net #rojo if you want to chat.
>
> Rojo is Hiring! - http://www.rojonetworks.com/JobsAtRojo.html
>
> Kevin A. Burton, Location - San Francisco, CA
> AIM/YIM - sfburtonator, Web - http://peerfear.org/
> GPG fingerprint: 5FB2 F3E2 760E 70A8 6174 D393 E84D 8D04 99F1 4412
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
>
>
--
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: The amazingly slow performance of JSP (profiler results)
Posted by Dakota Jack <da...@gmail.com>.
I agree with this. There really is *not* a lot of code in what Kevin
showed us, because the page code has to be there whether you have one
or 500 invocations, tags, on the page. This just makes it look large
because all the setup is attributed to one measely little tag.
On 5/28/05, Remy Maucherat <re...@gmail.com> wrote:
> On 5/28/05, Peter Lin <wo...@gmail.com> wrote:
> > as you see already, using JSTL means a single line of code gets
> > converted to several lines of JSTL api calls. once you look at how
> > many classes are involved in executing JSTL, it's pretty clear it's
> > using much more memory and causing more GC. The performance you see is
> > the result of JSTL using more memory.
>
> It will obviously use more CPU and make more API calls. However, it
> does not allocate any objects, but instead will reuse per page objects
> (which is very fast). So overall, it sounds weird to me that the
> bottleneck would be on tag invocation.
>
> In the end, it's hard to beat a Java "if" with a generic high level
> construct ;) I don't understand how anyone could be surprised by that.
>
> > Back in 2002, I wrote several pages using JSP + java and JSP + JSTL to
> > measure the actual cost of from a performance perspective. The
> > performance difference isn't noticeable if a page has less than 50
> > tags. With 200+ tags, the performance difference does range from 2-5x
> > slower for JSTL. It's worse when you use XML with JSTL. It's also one
> > of the reasons I like to use JSTL + XML to benchmark. It really gives
> > the VM a workout.
> >
> > have you tried running JRockit 5? I did some tests recently and
> > JRockit's memory management might give you a 2x improvement in
> > performance. That's assuming you can use jdk5
>
> Right, the code for invoking tags seems to be a good candidate to be
> optimized by a competent JIT.
>
> --
> xxxxxxxxxxxxxxxxxxxxxxxxx
> Rémy Maucherat
> Developer & Consultant
> JBoss Group (Europe) SàRL
> xxxxxxxxxxxxxxxxxxxxxxxxx
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
>
>
--
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: The amazingly slow performance of JSP (profiler results)
Posted by Peter Lin <wo...@gmail.com>.
On 5/28/05, Kevin Burton <bu...@rojo.com> wrote:
> Remy Maucherat wrote:
>
> >It will obviously use more CPU and make more API calls. However, it
> >does not allocate any objects, but instead will reuse per page objects
> >(which is very fast). So overall, it sounds weird to me that the
> >bottleneck would be on tag invocation.
> >
> >In the end, it's hard to beat a Java "if" with a generic high level
> >construct ;) I don't understand how anyone could be surprised by that.
> >
> >
> I think people are suprised because we don't realize that JSP is using
> such a high level overhead internally. People see the semantics of c:if
> and c:set and so forth and assume they're analogs for Java "if"
> semantics and assume they would perform at the same level.
>
> Its more obvious to you guys because you're usually delving into Tomcat
> at that level where I haven't done so in a long time (especially into
> Jasper generated source)l.
>
> Kevin
>
Ironically, that is the appeal and downside of JSTL. <c:if .... >
looks pretty innocent, until one realizes how many lines Jasper2
generates to setup the tag. Jasper2 does a much better job than
jasper1 in tomcat 4.0.x. If I remember correctly, jasper2 was first
released with jasper 4.1.x. The initial version of jasper2 fixed some
major performance issues like deeply nested try/catch and methods
exceeding java's line limit.
to be fair, the great thing about JSP tags and the tag API is it makes
it easy for tags to operate with each other. it makes is pretty easy
to mix and match JSTL with other tag libraries. the tag plugin API in
jasper2 is a great way to take if, when, foreach and convert those to
pure java. good luck
peter
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: The amazingly slow performance of JSP (profiler results)
Posted by Kevin Burton <bu...@rojo.com>.
Remy Maucherat wrote:
>It will obviously use more CPU and make more API calls. However, it
>does not allocate any objects, but instead will reuse per page objects
>(which is very fast). So overall, it sounds weird to me that the
>bottleneck would be on tag invocation.
>
>In the end, it's hard to beat a Java "if" with a generic high level
>construct ;) I don't understand how anyone could be surprised by that.
>
>
I think people are suprised because we don't realize that JSP is using
such a high level overhead internally. People see the semantics of c:if
and c:set and so forth and assume they're analogs for Java "if"
semantics and assume they would perform at the same level.
Its more obvious to you guys because you're usually delving into Tomcat
at that level where I haven't done so in a long time (especially into
Jasper generated source)l.
Kevin
--
Use Rojo (RSS/Atom aggregator)! - visit http://rojo.com.
See irc.freenode.net #rojo if you want to chat.
Rojo is Hiring! - http://www.rojonetworks.com/JobsAtRojo.html
Kevin A. Burton, Location - San Francisco, CA
AIM/YIM - sfburtonator, Web - http://peerfear.org/
GPG fingerprint: 5FB2 F3E2 760E 70A8 6174 D393 E84D 8D04 99F1 4412
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: The amazingly slow performance of JSP (profiler results)
Posted by Peter Lin <wo...@gmail.com>.
correction to my previous email.
On 5/28/05, Remy Maucherat <re...@gmail.com> wrote:
> On 5/28/05, Peter Lin <wo...@gmail.com> wrote:
> > as you see already, using JSTL means a single line of code gets
> > converted to several lines of JSTL api calls. once you look at how
> > many classes are involved in executing JSTL, it's pretty clear it's
> > using much more memory and causing more GC. The performance you see is
> > the result of JSTL using more memory.
>
> It will obviously use more CPU and make more API calls. However, it
> does not allocate any objects, but instead will reuse per page objects
> (which is very fast). So overall, it sounds weird to me that the
> bottleneck would be on tag invocation.
>
> In the end, it's hard to beat a Java "if" with a generic high level
> construct ;) I don't understand how anyone could be surprised by that.
>
I should note that the difference was greater in Jasper 1. The latest
jasper has improved over the original jasper, which is what I used to
compare JSTL vs Java. Remy's response reminded me of the differences,
so my statement may not be true for the latest jasper and would only
apply to the original jasper2. That version didn't have the tag plugin
or all the recent stuff in tomcat 5.5.x.
> > Back in 2002, I wrote several pages using JSP + java and JSP + JSTL to
> > measure the actual cost of from a performance perspective. The
> > performance difference isn't noticeable if a page has less than 50
> > tags. With 200+ tags, the performance difference does range from 2-5x
> > slower for JSTL. It's worse when you use XML with JSTL. It's also one
> > of the reasons I like to use JSTL + XML to benchmark. It really gives
> > the VM a workout.
> >
> > have you tried running JRockit 5? I did some tests recently and
> > JRockit's memory management might give you a 2x improvement in
> > performance. That's assuming you can use jdk5
>
> Right, the code for invoking tags seems to be a good candidate to be
> optimized by a competent JIT.
>
Don't know if anyone cares, but Resin's fastJSTL basically compiles to
java. Or atleast it used to when JSTL 1.0 was originally released.
Maybe it's just me, but I've come to expect tags to run slower and
make a butt load of more API calls. One tip that might help is to
increase the heap in tomcat. Before our application went into
production, I ran 12 different heap configurations and ran a suite of
JMeter stress tests to see which is optimal. good luck.
peter lin
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: The amazingly slow performance of JSP (profiler results)
Posted by Remy Maucherat <re...@gmail.com>.
On 5/28/05, Peter Lin <wo...@gmail.com> wrote:
> as you see already, using JSTL means a single line of code gets
> converted to several lines of JSTL api calls. once you look at how
> many classes are involved in executing JSTL, it's pretty clear it's
> using much more memory and causing more GC. The performance you see is
> the result of JSTL using more memory.
It will obviously use more CPU and make more API calls. However, it
does not allocate any objects, but instead will reuse per page objects
(which is very fast). So overall, it sounds weird to me that the
bottleneck would be on tag invocation.
In the end, it's hard to beat a Java "if" with a generic high level
construct ;) I don't understand how anyone could be surprised by that.
> Back in 2002, I wrote several pages using JSP + java and JSP + JSTL to
> measure the actual cost of from a performance perspective. The
> performance difference isn't noticeable if a page has less than 50
> tags. With 200+ tags, the performance difference does range from 2-5x
> slower for JSTL. It's worse when you use XML with JSTL. It's also one
> of the reasons I like to use JSTL + XML to benchmark. It really gives
> the VM a workout.
>
> have you tried running JRockit 5? I did some tests recently and
> JRockit's memory management might give you a 2x improvement in
> performance. That's assuming you can use jdk5
Right, the code for invoking tags seems to be a good candidate to be
optimized by a competent JIT.
--
xxxxxxxxxxxxxxxxxxxxxxxxx
Rémy Maucherat
Developer & Consultant
JBoss Group (Europe) SàRL
xxxxxxxxxxxxxxxxxxxxxxxxx
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: The amazingly slow performance of JSP (profiler results)
Posted by Kevin Burton <bu...@rojo.com>.
Peter Lin wrote:
>Back in 2002, I wrote several pages using JSP + java and JSP + JSTL to
>measure the actual cost of from a performance perspective. The
>performance difference isn't noticeable if a page has less than 50
>tags. With 200+ tags, the performance difference does range from 2-5x
>slower for JSTL. It's worse when you use XML with JSTL. It's also one
>of the reasons I like to use JSTL + XML to benchmark. It really gives
>the VM a workout.
>
>
Awesome! This is great validation.
At least I know I'm not hallucinating :)
The issue is that we have certainly more than 200+ tags... which I'm
not exactly happy about.
The other big performance hit was our use of custom .tag files? I was
able to get a chunk of code form 900ms down to 150ms by replacing the
use of a custom.tag into a jspf include.
Could this be that custom tags aren't using the tag pool?
My profiling showed that a bunch of methods here seemed to be based
around creation.
If necessary I can build up a test case and then profile it.
Kevin
--
Use Rojo (RSS/Atom aggregator)! - visit http://rojo.com.
See irc.freenode.net #rojo if you want to chat.
Rojo is Hiring! - http://www.rojonetworks.com/JobsAtRojo.html
Kevin A. Burton, Location - San Francisco, CA
AIM/YIM - sfburtonator, Web - http://peerfear.org/
GPG fingerprint: 5FB2 F3E2 760E 70A8 6174 D393 E84D 8D04 99F1 4412
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: The amazingly slow performance of JSP (profiler results)
Posted by Peter Lin <wo...@gmail.com>.
I would advise using the tag plugins to change tags to pure java. JSP
tags are considerably slower than pure JSP + java, but many people
find that combination bad on maintenance. When remy and I worked on
the book back in 2002, I did quite a bit of comparison between pure
java and JSTL.
as you see already, using JSTL means a single line of code gets
converted to several lines of JSTL api calls. once you look at how
many classes are involved in executing JSTL, it's pretty clear it's
using much more memory and causing more GC. The performance you see is
the result of JSTL using more memory.
Back in 2002, I wrote several pages using JSP + java and JSP + JSTL to
measure the actual cost of from a performance perspective. The
performance difference isn't noticeable if a page has less than 50
tags. With 200+ tags, the performance difference does range from 2-5x
slower for JSTL. It's worse when you use XML with JSTL. It's also one
of the reasons I like to use JSTL + XML to benchmark. It really gives
the VM a workout.
have you tried running JRockit 5? I did some tests recently and
JRockit's memory management might give you a 2x improvement in
performance. That's assuming you can use jdk5
peter
On 5/28/05, Kevin Burton <bu...@rojo.com> wrote:
> I've been tuning our application trying to get the maximum performance
> out if the system as possible.
>
> I've been throwing the system at jprofiler and allowing it to tell me
> where to optimized.
>
> In short Tomcat is slower than our DB, filesystem,. network and all
> other systems by about 4x.
>
> I've been able to shave some page load time off by some but not enough.
>
> The problem I'm starting to see is that we just have a large number of
> c:set and c:if constructs (and so forth) within loops. These loops then
> get executed 5 times and next thing you know it you have 50k taglib calls.
>
> The problem comes when you look at the source:
>
> Let's say you start with:
>
> > <c:set var="foo" value="bar"/>
>
> This nice little elegant piece of code gets expanded to:
>
> > private boolean _jspx_meth_c_set_0(PageContext _jspx_page_context)
> > throws Throwable {
> > PageContext pageContext = _jspx_page_context;
> > JspWriter out = _jspx_page_context.getOut();
> > // c:set
> > org.apache.taglibs.standard.tag.rt.core.SetTag _jspx_th_c_set_0 =
> > (org.apache.taglibs.standard.tag.rt.core.SetTag)
> > _jspx_tagPool_c_set_var_value_nobody.get(org.apache.taglibs.standard.tag.rt.core.SetTag.class);
> > _jspx_th_c_set_0.setPageContext(_jspx_page_context);
> > _jspx_th_c_set_0.setParent(null);
> > _jspx_th_c_set_0.setVar("foo");
> > _jspx_th_c_set_0.setValue(new String("bar"));
> > int _jspx_eval_c_set_0 = _jspx_th_c_set_0.doStartTag();
> > if (_jspx_th_c_set_0.doEndTag() ==
> > javax.servlet.jsp.tagext.Tag.SKIP_PAGE)
> > return true;
> > _jspx_tagPool_c_set_var_value_nobody.reuse(_jspx_th_c_set_0);
> > return false;
> > }
>
> Which explains why JSP alone is so amazingly slow!
>
>
> I did a comparison of the page performance here and it was 15x slower than just using Java. So the same "set" operation in Java was 15x faster.
>
> ... so in short ... does anyone have any way to speed this up?
>
> The other thing I noticed is that EL is evaluated at runtime (which has to be parsed) and sometimes uses reflections. Can anyone shed any more light on this and hopefully provide some performance optimization suggestions?
>
> Kevin
>
> --
>
>
> Use Rojo (RSS/Atom aggregator)! - visit http://rojo.com.
> See irc.freenode.net #rojo if you want to chat.
>
> Rojo is Hiring! - http://www.rojonetworks.com/JobsAtRojo.html
>
> Kevin A. Burton, Location - San Francisco, CA
> AIM/YIM - sfburtonator, Web - http://peerfear.org/
> GPG fingerprint: 5FB2 F3E2 760E 70A8 6174 D393 E84D 8D04 99F1 4412
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: The amazingly slow performance of JSP (profiler results)
Posted by Kevin Burton <bu...@rojo.com>.
Peng Tuck Kwok wrote:
>Just to check are your precompiling the jsp page?
>
>
>
Yes... we're precompiling them before we deploy. I'd recommend most
people do that if they have the time.
Kevin
--
Use Rojo (RSS/Atom aggregator)! - visit http://rojo.com.
See irc.freenode.net #rojo if you want to chat.
Rojo is Hiring! - http://www.rojonetworks.com/JobsAtRojo.html
Kevin A. Burton, Location - San Francisco, CA
AIM/YIM - sfburtonator, Web - http://peerfear.org/
GPG fingerprint: 5FB2 F3E2 760E 70A8 6174 D393 E84D 8D04 99F1 4412
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: The amazingly slow performance of JSP (profiler results)
Posted by Dakota Jack <da...@gmail.com>.
Whether he is precompiling or not, Peng, and I know that is important,
he is still comparing applies and oranges. Further, he is comparing
the setup for any and all uses of <c:set> with pojo code that he does
not give the same infrastructure accounting, apparently. The whole
question fails to see the parameters of the test situation.
On 5/28/05, Peng Tuck Kwok <pe...@gmail.com> wrote:
> Just to check are your precompiling the jsp page?
>
> On 5/28/05, Kevin Burton <bu...@rojo.com> wrote:
> > I've been tuning our application trying to get the maximum performance
> > out if the system as possible.
> >
> > I've been throwing the system at jprofiler and allowing it to tell me
> > where to optimized.
> >
> > In short Tomcat is slower than our DB, filesystem,. network and all
> > other systems by about 4x.
> >
> > I've been able to shave some page load time off by some but not enough.
> >
> > The problem I'm starting to see is that we just have a large number of
> > c:set and c:if constructs (and so forth) within loops. These loops then
> > get executed 5 times and next thing you know it you have 50k taglib calls.
> >
> > The problem comes when you look at the source:
> >
> > Let's say you start with:
> >
> > > <c:set var="foo" value="bar"/>
> >
> > This nice little elegant piece of code gets expanded to:
> >
> > > private boolean _jspx_meth_c_set_0(PageContext _jspx_page_context)
> > > throws Throwable {
> > > PageContext pageContext = _jspx_page_context;
> > > JspWriter out = _jspx_page_context.getOut();
> > > // c:set
> > > org.apache.taglibs.standard.tag.rt.core.SetTag _jspx_th_c_set_0 =
> > > (org.apache.taglibs.standard.tag.rt.core.SetTag)
> > > _jspx_tagPool_c_set_var_value_nobody.get(org.apache.taglibs.standard.tag.rt.core.SetTag.class);
> > > _jspx_th_c_set_0.setPageContext(_jspx_page_context);
> > > _jspx_th_c_set_0.setParent(null);
> > > _jspx_th_c_set_0.setVar("foo");
> > > _jspx_th_c_set_0.setValue(new String("bar"));
> > > int _jspx_eval_c_set_0 = _jspx_th_c_set_0.doStartTag();
> > > if (_jspx_th_c_set_0.doEndTag() ==
> > > javax.servlet.jsp.tagext.Tag.SKIP_PAGE)
> > > return true;
> > > _jspx_tagPool_c_set_var_value_nobody.reuse(_jspx_th_c_set_0);
> > > return false;
> > > }
> >
> > Which explains why JSP alone is so amazingly slow!
> >
> >
> > I did a comparison of the page performance here and it was 15x slower than just using Java. So the same "set" operation in Java was 15x faster.
> >
> > ... so in short ... does anyone have any way to speed this up?
> >
> > The other thing I noticed is that EL is evaluated at runtime (which has to be parsed) and sometimes uses reflections. Can anyone shed any more light on this and hopefully provide some performance optimization suggestions?
> >
> > Kevin
> >
> > --
> >
> >
> > Use Rojo (RSS/Atom aggregator)! - visit http://rojo.com.
> > See irc.freenode.net #rojo if you want to chat.
> >
> > Rojo is Hiring! - http://www.rojonetworks.com/JobsAtRojo.html
> >
> > Kevin A. Burton, Location - San Francisco, CA
> > AIM/YIM - sfburtonator, Web - http://peerfear.org/
> > GPG fingerprint: 5FB2 F3E2 760E 70A8 6174 D393 E84D 8D04 99F1 4412
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
>
>
--
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: The amazingly slow performance of JSP (profiler results)
Posted by Peng Tuck Kwok <pe...@gmail.com>.
Just to check are your precompiling the jsp page?
On 5/28/05, Kevin Burton <bu...@rojo.com> wrote:
> I've been tuning our application trying to get the maximum performance
> out if the system as possible.
>
> I've been throwing the system at jprofiler and allowing it to tell me
> where to optimized.
>
> In short Tomcat is slower than our DB, filesystem,. network and all
> other systems by about 4x.
>
> I've been able to shave some page load time off by some but not enough.
>
> The problem I'm starting to see is that we just have a large number of
> c:set and c:if constructs (and so forth) within loops. These loops then
> get executed 5 times and next thing you know it you have 50k taglib calls.
>
> The problem comes when you look at the source:
>
> Let's say you start with:
>
> > <c:set var="foo" value="bar"/>
>
> This nice little elegant piece of code gets expanded to:
>
> > private boolean _jspx_meth_c_set_0(PageContext _jspx_page_context)
> > throws Throwable {
> > PageContext pageContext = _jspx_page_context;
> > JspWriter out = _jspx_page_context.getOut();
> > // c:set
> > org.apache.taglibs.standard.tag.rt.core.SetTag _jspx_th_c_set_0 =
> > (org.apache.taglibs.standard.tag.rt.core.SetTag)
> > _jspx_tagPool_c_set_var_value_nobody.get(org.apache.taglibs.standard.tag.rt.core.SetTag.class);
> > _jspx_th_c_set_0.setPageContext(_jspx_page_context);
> > _jspx_th_c_set_0.setParent(null);
> > _jspx_th_c_set_0.setVar("foo");
> > _jspx_th_c_set_0.setValue(new String("bar"));
> > int _jspx_eval_c_set_0 = _jspx_th_c_set_0.doStartTag();
> > if (_jspx_th_c_set_0.doEndTag() ==
> > javax.servlet.jsp.tagext.Tag.SKIP_PAGE)
> > return true;
> > _jspx_tagPool_c_set_var_value_nobody.reuse(_jspx_th_c_set_0);
> > return false;
> > }
>
> Which explains why JSP alone is so amazingly slow!
>
>
> I did a comparison of the page performance here and it was 15x slower than just using Java. So the same "set" operation in Java was 15x faster.
>
> ... so in short ... does anyone have any way to speed this up?
>
> The other thing I noticed is that EL is evaluated at runtime (which has to be parsed) and sometimes uses reflections. Can anyone shed any more light on this and hopefully provide some performance optimization suggestions?
>
> Kevin
>
> --
>
>
> Use Rojo (RSS/Atom aggregator)! - visit http://rojo.com.
> See irc.freenode.net #rojo if you want to chat.
>
> Rojo is Hiring! - http://www.rojonetworks.com/JobsAtRojo.html
>
> Kevin A. Burton, Location - San Francisco, CA
> AIM/YIM - sfburtonator, Web - http://peerfear.org/
> GPG fingerprint: 5FB2 F3E2 760E 70A8 6174 D393 E84D 8D04 99F1 4412
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: The amazingly slow performance of JSP (profiler results)
Posted by Kevin Burton <bu...@rojo.com>.
Remy Maucherat wrote:
>
>For production configuration for Jasper, see:
>http://jakarta.apache.org/tomcat/tomcat-5.5-doc/jasper-howto.html#Production%20Configuration
>
>
Do you know offhand if genStrAsCharArray has to be passed to jspc? I
didn't notice this as one of the command line options in 5.5.x... We
have it set in our web.xml but something says that won't matter since
we're precompiling our webapps.
Kevin
--
Use Rojo (RSS/Atom aggregator)! - visit http://rojo.com.
See irc.freenode.net #rojo if you want to chat.
Rojo is Hiring! - http://www.rojonetworks.com/JobsAtRojo.html
Kevin A. Burton, Location - San Francisco, CA
AIM/YIM - sfburtonator, Web - http://peerfear.org/
GPG fingerprint: 5FB2 F3E2 760E 70A8 6174 D393 E84D 8D04 99F1 4412
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: The amazingly slow performance of JSP (profiler results)
Posted by Kevin Burton <bu...@rojo.com>.
Remy Maucherat wrote:
> For production configuration for Jasper, see:
>
>http://jakarta.apache.org/tomcat/tomcat-5.5-doc/jasper-howto.html#Production%20Configuration
>
>
>
Cool... we have those set but I didn't see *genStrAsCharArray
*
**The interesting thing is that jprofiler clearly shows a big
performance hit when development is set to "true" btw.
I'll try to play with the above setting... thanks.
Kevin
--
Use Rojo (RSS/Atom aggregator)! - visit http://rojo.com.
See irc.freenode.net #rojo if you want to chat.
Rojo is Hiring! - http://www.rojonetworks.com/JobsAtRojo.html
Kevin A. Burton, Location - San Francisco, CA
AIM/YIM - sfburtonator, Web - http://peerfear.org/
GPG fingerprint: 5FB2 F3E2 760E 70A8 6174 D393 E84D 8D04 99F1 4412
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: The amazingly slow performance of JSP (profiler results)
Posted by Remy Maucherat <re...@gmail.com>.
On 5/28/05, Kevin Burton <bu...@rojo.com> wrote:
> I've been tuning our application trying to get the maximum performance
> out if the system as possible.
>
> I've been throwing the system at jprofiler and allowing it to tell me
> where to optimized.
>
> In short Tomcat is slower than our DB, filesystem,. network and all
> other systems by about 4x.
>
> I've been able to shave some page load time off by some but not enough.
>
> The problem I'm starting to see is that we just have a large number of
> c:set and c:if constructs (and so forth) within loops. These loops then
> get executed 5 times and next thing you know it you have 50k taglib calls.
>
> The problem comes when you look at the source:
>
> Let's say you start with:
>
> > <c:set var="foo" value="bar"/>
>
> This nice little elegant piece of code gets expanded to:
>
> > private boolean _jspx_meth_c_set_0(PageContext _jspx_page_context)
> > throws Throwable {
> > PageContext pageContext = _jspx_page_context;
> > JspWriter out = _jspx_page_context.getOut();
> > // c:set
> > org.apache.taglibs.standard.tag.rt.core.SetTag _jspx_th_c_set_0 =
> > (org.apache.taglibs.standard.tag.rt.core.SetTag)
> > _jspx_tagPool_c_set_var_value_nobody.get(org.apache.taglibs.standard.tag.rt.core.SetTag.class);
> > _jspx_th_c_set_0.setPageContext(_jspx_page_context);
> > _jspx_th_c_set_0.setParent(null);
> > _jspx_th_c_set_0.setVar("foo");
> > _jspx_th_c_set_0.setValue(new String("bar"));
> > int _jspx_eval_c_set_0 = _jspx_th_c_set_0.doStartTag();
> > if (_jspx_th_c_set_0.doEndTag() ==
> > javax.servlet.jsp.tagext.Tag.SKIP_PAGE)
> > return true;
> > _jspx_tagPool_c_set_var_value_nobody.reuse(_jspx_th_c_set_0);
> > return false;
> > }
>
> Which explains why JSP alone is so amazingly slow!
>
>
> I did a comparison of the page performance here and it was 15x slower than just using Java. So the same "set" operation in Java was 15x faster.
>
> ... so in short ... does anyone have any way to speed this up?
>
> The other thing I noticed is that EL is evaluated at runtime (which has to be parsed) and sometimes uses reflections. Can anyone shed any more light on this and hopefully provide some performance optimization suggestions?
You already posted on this subject. Can you provide any hard data that
a tag invocation is actually slow this time ? Guesses don't really do
it, and profilers are often not very accurate. I'm asking because
while the code is indeed quite verbose, it does not make it slow (all
operations in the code that is cut & pasted are very cheap). The JIT
is supposed to take care of this kind of code very well.
For production configuration for Jasper, see:
http://jakarta.apache.org/tomcat/tomcat-5.5-doc/jasper-howto.html#Production%20Configuration
We have a facility in Jasper called tag plugins, which allows
replacing a tag invocation (which cannot be any simpler and still
comply to the specification) by equivalent Java code (so your c:if is
traslated to a regular Java "if"). Support for JSTL is very
incomplete, but you can use that to optimize the few tags that you
think need it. Kin-Man asserted that overall the performance
improvement was small - 10% at most. See package
org.apache.jasper.tagplugins.jstl (which has already an impl for "if"
which could help you out). Feel free to sumit more JSTL tag plugins if
you find it works well.
EL will have to remain interpreted at runtime, but has a cache. I have
not evaluated this performance area yet, however. Other xSP
technologies interpret a lot of things at runtime, and most don't even
rely on compilation (which will likely tend to make them a little
slower, I assume), and the overhead is usually not in the xSP engine,
so I don't see why it would be a major issue here (as long as the impl
is not too stupid, of course).
--
xxxxxxxxxxxxxxxxxxxxxxxxx
Rémy Maucherat
Developer & Consultant
JBoss Group (Europe) SàRL
xxxxxxxxxxxxxxxxxxxxxxxxx
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org