On 20/03/2019 05:13, Thibault Kruse wrote:
> Hi,
>
> when migrating from Tomcat7 to Tomcat8 for an application using javax-el
> expression evaluation on every request, we noticed a significant
> performance impact.
Try the latest 8.5.x implementation.
There are changes in Java EE 7 to the EL syntax that do have a negative
performance impact. We have made various changes over the years to
address these. If you test with the latest 8.5.x implementation (8.5.39
was released yesterday and the formal announcement will be going out
shortly) you should see some improvement.
If you still see an issue, a simple test case that reproduces the issue
would be appreciated.
Finally, note that org.mortbay.jasper:apache-el:8.0.33 is not something
that has been released by the Tomcat project.
Mark
>
> Analyzing it, we see that a call sequence like for
> ValueExpression.getValue():
>
>
> ExpressionFactory expressionFactory = new ExpressionFactoryImpl();
> CompositeELResolver elResolver = new CompositeELResolver();
> elResolver.add(new ArrayELResolver());
> elResolver.add(new ListELResolver());
> elResolver.add(new BeanELResolver());
> elResolver.add(new MapELResolver());
> elContext = new ELContext() {
> public ELResolver getELResolver() {return elResolver;}
> }
> ValueExpression ve =
> expressionFactory.createValueExpression(elContext, "...",
> Object.class);
>
> final Object result = ve.getValue(elContext);
>
> calls in tomcat-jasper-el:7.0.8:
>
> * valueExpressionLiteral.getValue(context);
> * ELSupport.coerceToType(Object obj = "foo", Class<?> type =
> java.lang.Object.class)
>
> * returns "foo"
>
>
> whereas in org.mortbay.jasper:apache-el:8.0.33, the call becomes
>
> * valueExpressionLiteral.getValue(context);
>
> * ELContext.convertToType(Object obj = "foo", Class<?> type =
> java.lang.Object.class)
> * elresolver.convertToType(this, obj, type); // returns null
> * ELManager.getExpressionFactory().coerceToType(obj, type)
> * ELSupport.coerceToType(Object obj = "foo", Class<?> type =
> java.lang.Object.class)
>
> The getExpressionFactory() step in particular seems to cause harm in
> the server environment due to the impact of the ReadWriteLock.
>
> Note that what happens here is only the attempt to coerce the String
> "foo" to class Object.
>
> So the additional indirections added to
> valueExpressionLiteral.getValue() seem to be quite unnecessary for
> coercions to Object or to a class that the value is assignable from.
>
> And those indirections hurt performance badly.
>
> So I wonder whether this is a bug/weakness that should be adressed (I
> can provide a more reproducible example than baove in that case), or
> whether there is a simple ELResolver class that we should add to our
> CompositeELResolver to avoid this overhead.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
