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. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
