You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Adrian Gonzalez <ad...@yahoo.fr> on 2011/09/08 11:40:29 UTC
Re : Re : Re : Re : Performance issue in simpleTags and tagfiles
> The parsed expressions are already cached. I don't think there is any scope for further caching here.
Parsed expressions are cached as org.apache.el.parser.Node instances (in ExpressionBuilder#createNodeInternal) - if I understood correctly.
What I was think was to cache javax.el.ValueExpression instances, but not sure if it's correct to cache those instances (what's scope ?).
For instance, in a jsp compiled code, we have multiple calls to PageContextImpl.proprietaryEvaluate.
proprietaryEvaluate calls createValueExpression and getValue.
In a sample
* 28% of proprietaryEvaluate time is spent on createValueExpression,
* 45% is spent on getValue
----- Mail original -----
De : Mark Thomas <ma...@apache.org>
À : Tomcat Users List <us...@tomcat.apache.org>
Cc :
Envoyé le : Jeudi 8 Septembre 2011 11h28
Objet : Re: Re : Re : Re : Performance issue in simpleTags and tagfiles
On 08/09/2011 09:59, Adrian Gonzalez wrote:
> Just downloaded JProfiler eval.
>
> Compared tagfile performance between 7.0.21 and 7.0.trunk (this one this time : http://svn.apache.org/repos/asf/tomcat/tc7.0.x/trunk/)
>
> With your optimization, we achieve a 24% performance gain - nice ;)
>
> Test 7.0.21 7.0.trunk
> tagfile 267ms 206ms
>
> You can see JConsole output
> * 7.0.21 : http://imageshack.us/photo/my-images/233/tagperftagfile7021.jpg/
> * 7.0.trunk : http://imageshack.us/photo/my-images/52/tagperftagfile70trunk.jpg/
>
> Tests were made with http://localhost:8080/tagfilesperf/generated/edit-tagfile.jsp
>
>
> One more question though :
> Do you think we can cache ValueExpression instances ?
The parsed expressions are already cached. I don't think there is any
scope for further caching here.
I'll take another look with the profiler just to be sure.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Re : Re : Re : Re : Re : Re : Performance issue in simpleTags
and tagfiles
Posted by Mark Thomas <ma...@apache.org>.
On 08/09/2011 13:50, Adrian Gonzalez wrote:
> Thanks very much Mark for all the work on this issue !
>
> Do you know which version of tomcat will contain the improvements you've made ?
7.0.22 onwards.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re : Re : Re : Re : Re : Re : Performance issue in simpleTags and tagfiles
Posted by Adrian Gonzalez <ad...@yahoo.fr>.
Thanks very much Mark for all the work on this issue !
Do you know which version of tomcat will contain the improvements you've made ?
----- Mail original -----
De : Mark Thomas <ma...@apache.org>
À : Tomcat Users List <us...@tomcat.apache.org>
Cc :
Envoyé le : Jeudi 8 Septembre 2011 14h24
Objet : Re: Re : Re : Re : Re : Re : Performance issue in simpleTags and tagfiles
On 08/09/2011 12:19, Adrian Gonzalez wrote:
> Thanks Mark !
>
>> It should be possible to cache the ValueExpression per JSP page (in the PageContext)
>
> Yes, but the PageContext life's span is more or less a user request, no ?
Correct. I should have said via the PageContext since that is all that
is available at the point where the cache would be used.
> In this case, ValueExpression caching will only be useful when exactly the same expression is used multiple times in the same JSP. And I agree that we are improving there a micro-benchmark.
>
> What I was thinking was more about caching ValueExpression per class of JSP (i.e. one cache for edit_002dclassictag_jsp.java) - the cache being shared by all users of the application.
Agreed.
> WDYT ?
I think it is worth a try. I tried it and saw no improvement. If there
was going to be any benefit then this use case is where I'd expect to
see it so I think we can conclude there is little more to be done here.
It appears the overhead of the cache is roughly the same as the overhead
of creating the value expression (or both are so small that other
factors are dominating).
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Re : Re : Re : Re : Re : Performance issue in simpleTags and
tagfiles
Posted by Mark Thomas <ma...@apache.org>.
On 08/09/2011 12:19, Adrian Gonzalez wrote:
> Thanks Mark !
>
>> It should be possible to cache the ValueExpression per JSP page (in the PageContext)
>
> Yes, but the PageContext life's span is more or less a user request, no ?
Correct. I should have said via the PageContext since that is all that
is available at the point where the cache would be used.
> In this case, ValueExpression caching will only be useful when exactly the same expression is used multiple times in the same JSP. And I agree that we are improving there a micro-benchmark.
>
> What I was thinking was more about caching ValueExpression per class of JSP (i.e. one cache for edit_002dclassictag_jsp.java) - the cache being shared by all users of the application.
Agreed.
> WDYT ?
I think it is worth a try. I tried it and saw no improvement. If there
was going to be any benefit then this use case is where I'd expect to
see it so I think we can conclude there is little more to be done here.
It appears the overhead of the cache is roughly the same as the overhead
of creating the value expression (or both are so small that other
factors are dominating).
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re : Re : Re : Re : Re : Performance issue in simpleTags and tagfiles
Posted by Adrian Gonzalez <ad...@yahoo.fr>.
Thanks Mark !
> It should be possible to cache the ValueExpression per JSP page (in the PageContext)
Yes, but the PageContext life's span is more or less a user request, no ?
In this case, ValueExpression caching will only be usefull when exactly the same expression is used multiple times in the same JSP. And I agree that we are improving there a micro-benchmark.
What I was thinking was more about caching ValueExpression per class of JSP (i.e. one cache for edit_002dclassictag_jsp.java) - the cache being shared by all users of the application.
WDYT ?
----- Mail original -----
De : Mark Thomas <ma...@apache.org>
À : Tomcat Users List <us...@tomcat.apache.org>
Cc :
Envoyé le : Jeudi 8 Septembre 2011 13h09
Objet : Re: Re : Re : Re : Re : Performance issue in simpleTags and tagfiles
On 08/09/2011 10:40, Adrian Gonzalez wrote:
>> The parsed expressions are already cached. I don't think there is
>> any scope for further caching here.
>
>
> Parsed expressions are cached as org.apache.el.parser.Node instances
> (in ExpressionBuilder#createNodeInternal) - if I understood
> correctly.
Correct.
> What I was think was to cache javax.el.ValueExpression
> instances, but not sure if it's correct to cache those instances
> (what's scope ?).
This isn't the biggest delay in my profiling (I use YourKit) whether I
use sampling or tracing which just goes to show how much variation you
can get from system to system and with different profilers. In my
results, annotation scanning is still an issue for postConstruct /
preDestroy. Enhancing the caching to handle these as well gives the
following (with profiling disabled):
The figures I saw were:
Test OP Me Cached Cached2
tagfile 500 328 203 125
classic 100 141 156 141
simple 500 250 156 125
none 94 140 156 141
I've added that caching to trunk and tc7.0.x/trunk.
With that problem fixed, the sampling and tracing show very different
results which suggests to me that the tracing overhead is starting to
dominate the results.
> For instance, in a jsp compiled code, we have multiple calls to
> PageContextImpl.proprietaryEvaluate. proprietaryEvaluate calls
> createValueExpression and getValue.
>
> In a sample * 28% of proprietaryEvaluate time is spent on
> createValueExpression, * 45% is spent on getValue
The results of getValue can't be cached since the values of the resolved
attributes may change between invocations.
It should be possible to cache the ValueExpression per JSP page (in the
PageContext) but I am not sure how much that will gain you. We may be
into the realm of improving the results of a micro benchmark rather than
generally improving performance. I'll take a look.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Re : Re : Re : Re : Performance issue in simpleTags and tagfiles
Posted by Mark Thomas <ma...@apache.org>.
On 08/09/2011 10:40, Adrian Gonzalez wrote:
>> The parsed expressions are already cached. I don't think there is
>> any scope for further caching here.
>
>
> Parsed expressions are cached as org.apache.el.parser.Node instances
> (in ExpressionBuilder#createNodeInternal) - if I understood
> correctly.
Correct.
> What I was think was to cache javax.el.ValueExpression
> instances, but not sure if it's correct to cache those instances
> (what's scope ?).
This isn't the biggest delay in my profiling (I use YourKit) whether I
use sampling or tracing which just goes to show how much variation you
can get from system to system and with different profilers. In my
results, annotation scanning is still an issue for postConstruct /
preDestroy. Enhancing the caching to handle these as well gives the
following (with profiling disabled):
The figures I saw were:
Test OP Me Cached Cached2
tagfile 500 328 203 125
classic 100 141 156 141
simple 500 250 156 125
none 94 140 156 141
I've added that caching to trunk and tc7.0.x/trunk.
With that problem fixed, the sampling and tracing show very different
results which suggests to me that the tracing overhead is starting to
dominate the results.
> For instance, in a jsp compiled code, we have multiple calls to
> PageContextImpl.proprietaryEvaluate. proprietaryEvaluate calls
> createValueExpression and getValue.
>
> In a sample * 28% of proprietaryEvaluate time is spent on
> createValueExpression, * 45% is spent on getValue
The results of getValue can't be cached since the values of the resolved
attributes may change between invocations.
It should be possible to cache the ValueExpression per JSP page (in the
PageContext) but I am not sure how much that will gain you. We may be
into the realm of improving the results of a micro benchmark rather than
generally improving performance. I'll take a look.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org