tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Thomas <>
Subject Re: Another attempt at discussing the major performance issue in Tomcat 8 JSP
Date Thu, 08 Oct 2015 14:18:12 GMT
On 08/10/2015 14:24, sebdotv wrote:
> Mark, thanks for your quick and detailed answer.
>> Hmm. With 9.0.x trunk there are 4 calls, not 12 to loadClass. One (not
>> three) for each package. I can't immediately think of any reason why
>> 8.0.x would make additional calls. Having checked, it doesn't. 8.0.x
>> makes 4 calls just like 9.0.x. I don't see anything that would have
>> changed this since 8.0.27.
> You're right, I was counting recursive calls in the classloader. 1
> call is indeed made per package, so here 4 calls per undefined
> attribute.
>> Regardless of whether there are 4 or 12 calls, I agree the performance
>> impact is going to be significant. The time is mostly spent constructing
>> the ClassNotFoundException. Annoyingly, this is then thrown away. As set
>> out in [1], there is a work-around but that comes with its own
>> performance impact and it is currently the view that we don't want to
>> slow down valid lookups to make invalid lookups faster.
> Not that it matters much at this point, but I am not seeing so much of
> the time constructing the exception. A good part of the time is spent
> blocking on WebappClassLoader, unless ParallelWebappClassLoader is
> used. Then the loading of a class means searching for it everywhere on
> the classpath, which takes time (IO). Of course classloaders should
> not be used in vain, especially not repeatedly.

If you have a lot of pages like this then under load the blocking in the
class loader could start to dominate the delay. My comment about
exception construction was with a single-threaded test if I remember
correctly. It sounds as if parallel class loader may help at least a
little in your case.

>>> - if everything is conform with the spec, a more aggressive cache should
>>> probably be implemented and used by ImportHandler
>> That is a lot easier said than done.
>> - A new ImportHandler instance is required for every page request
>> - Each page can have a different set of imports
>> - ImportHandler is spec class used by multiple web applications each of
>>   which will have a different set of classes available
>> - The cache needs to be thread safe
>> - The cache needs to be self-limiting in size
> Not knowing anything about the internals of Tomcat, but what about
> something like a concurrent hashmap with weak keys (classloader +
> name) and values (class), used in ImportHandler.findClass? Do you
> foresee issues with something along these lines?

That is the sort of thing I had in mind as a static in ImportHandler.
Doing this and limiting the size of the cache could be tricky and -
since the maximum size of the cache depends on the application not user
input - you could argue there is no need for limiting the size.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message