Hi Carsten, you are right regarding your assumption about the calls to getResource().
I also tend to agree with your benchmark results. I have a filter, which injects a custom ResourceResolver wrapping the "real" one, but implements caching use a WeakHashMap. I see that I am able to reduce the time for the getResource() call to 10% if the cache is used (constantly less than 1000 nanoseconds to times typically in the area of 10'000 nanoseconds if the actual call to the wrapped RR is made); but interestingly a short run of apachebench did not show any improvements, rather the opposite. I see the biggest benefit of reusing a cached resource in the fact, that after the first read of (JCR) resource properties from the underlying layer these properties are cached within the resource. And profiling data from 3 years ago (Oak 1.0 times) showed, that Oak itself can consume significant amounts of CPU cycles. But the fact, that this improvement is not reflected in the response times, makes me think. Actually, my initial attempt was to log all requests to resources to identify hotspots in resource usage. And from there trying to find out which code is actually causing these many requests. So adding the cache was just an experiment :-) I try to polish my code a bit and provide it somewhere for others to play with it. regards, Jörg Am Mo., 30. Sept. 2019 um 08:51 Uhr schrieb Carsten Ziegeler < cziege...@apache.org>: > I guess it's not the resource resolver calling getResource() but code > using the resource resolver calling it over and over again, right? > > It's correct that the javadoc does not state whether a new resource > object is returned or a previous one. Client code should not make any > assumptions about this. So you could return the same object. > > Years ago I did a simple caching implementation for the same reasons you > mention :) and although getResource was called over and over again with > the same path during a single request, the caching did not provide any > significant benefit as not getting the resource but the operations on > the returned resource where the part where most time was spent. That > might have changed, but its something to look at. And obviously instead > of trying to implement lower level caching, its better to avoid the many > calls in the first place. > > Regards > Carsten > > Am 30.09.2019 um 08:00 schrieb Jörg Hoh: > > Hi, > > > > I am currently looking performance-wise on the resourceResolver; I found > > that during request handling a single resource resolver often calls > > getResource() for the same path. And before I start researching ways to > > optimize it (caching is quite obvious), I would like know about the > > detailed semantics of getResource(). > > > > Resource r1 = resourceResolver.getResource(path); > > Resource r2 = resourceResolver.getResource(path); > > > > I haven't in the javadoc any statement about the relation between these > > two, especially if it's mandatory that r1 != r2 (which is the current > > implementation). If there are requirements towards this, I would try to > > come up with an implementation in which r1 == r2. > > > > WDYT? > > > > Jörg > > > > -- > -- > Carsten Ziegeler > Adobe Research Switzerland > cziege...@apache.org > -- Cheers, Jörg Hoh, http://cqdump.wordpress.com Twitter: @joerghoh
