Thanks Jörg
so it seems you ended up with the same results, I wrote a "logging" RR
wrapper for the same reason. In my case the calling code was so complex
that it was just too much work to rewrite it to do less resource calls.
Regards
Carsten
Am 30.09.2019 um 22:35 schrieb Jörg Hoh:
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 <
[email protected]>:
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
[email protected]
--
--
Carsten Ziegeler
Adobe Research Switzerland
[email protected]
