tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Konstantin Kolinko <>
Subject Re: Resources - Performance (caching)
Date Thu, 20 Sep 2012 16:05:12 GMT
2012/9/20 Mark Thomas <>:
> On 09/09/2012 19:51, Mark Thomas wrote:
>> On 09/09/2012 19:44, Mark Thomas wrote:
>>> This is part of issue b) in Konstantin's comments in TOMCAT-NEXT.txt
>>> The current DirContext implementation supports caching in most but not
>>> all circumstances. It would be possible to insert a cache into the
>>> StandardRoot implementation but I am not convinced it is necessary. The
>>> read-cache built into most HDDs may be sufficient. Before starting a
>>> cache implementation, I would like to see some performance test cases
>>> that demonstrate that the DirContext implementation with caching is
>>> significantly faster than the new implementation without caching.
>> I would add that if even if the new implementation without caching
>> performs roughly the same as the old implementation with caching but
>> adding caching makes the new implementation even faster than that would
>> also convince me of the need to add caching although not with the same
>> priority.
> And that is why we do performance testing rather than making assumptions
> about what we think the performance will be.
> A simple JMeter test requesting the same static file over and over again
> shows that the original DirContext implementation is around 5 times
> faster than the new Resources implementation.
> I think the do we need caching question has just been answered firmly "Yes!"
> Using YourKit, I can see where problems are. I can improve the new
> implementation to only 3 times slower with some very simple caching
> within a single request but for improvement beyond that we will need
> caching of resources across requests that includes caching of content.
> I plan to look at this next.

Hi, Mark!

I suspect the slowest scenario will be when a file is served from a
META-INF/resources directory of a jar file.

I wonder what the numbers will be and whether there is already some
caching to prevent re-opening the jar file on each access.

There is a related issue in WebappClassLoader that I filed here:

I think I'll have time for more detailed review on this weekend.

Best regards,
Konstantin Kolinko

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

View raw message