jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vikas Saurabh <vikas.saur...@gmail.com>
Subject Re: [Document Cache Size] Is it better to have cache size using number of entries
Date Wed, 20 Aug 2014 08:50:33 GMT
>> why is 256MB -- the default value -- sufficient/insufficient
> We don't know. But how do you know that a cache of 10'000 "entries" is
> sufficient? Specially if each entry can be either 1 KB or 1 MB or 20 MB.
> The available memory can be divided into different areas, and each
> component is given a part of that. Then you look at performance, and see
> which component is slow, and you try to find out why. For example, it also
> depends on how expensive a cache miss is.

Yes, I agree... I was thinking more around this and realized that what
I was missing while debugging our issue wasn't configuration freedom
(in terms of entries) rather an easier way to analyze. Cache
hits/misses felt a bit inadequate -- but that can be because we were
hitting an entirely different issue and cache hit/miss numbers weren't
an issue for us. For us, increasing cache size improved performance
which was the red herring -- the performance soon dropped back and we
were left wondering if 2GB (that's the size we went for) isn't cutting
it. We wondered if there is a way to empirically figure out if we are
shooting blank arrows or not.
So, yes, I agree that may be configuration in terms of entries isn't
very useful (from a outside oak world point of view... internal reason
might still apply)... but, I also feel that we are lacking some
tooling (I can't really comment what would be useful or not) to
investigate. I feel hit/miss numbers aren't apparent enough.

> As for the cache size in amout of memory: the best way to know what a good
> number is, is to analyze the performance (how much time is spent reading,
> cache hit ratio,...)
We were running simple page loads -- some of them as trivial as single
page rendering based on one resource (and lots of js,css + page
rendering scripts + page and component nodes). We often found that
first rendering took significantly more time and subsequent reads
improved -- this is what directed us towards suspecting cache being
the issue. We did reset cache stats and soon cache hit reached around
82%-85% (while on a local dev setup it hung above 98). We tried
checking out what documents exists in the cache (using script console
and a small groovy script) and there were lots which I wasn't touching
directly (e.g. index etc)... and I didn't know if they were even
relevant for our page rendering or not. I agree I could really start
analyzing subset of cache entries but there were lots (around 31k
afair) and I just didn't have enough energy to delve further.
So, it might that I could debug the issue further to confirm that
cache wasn't the issue -- but on the other hand, I felt that there
should be better ways to understand what's going on.

>> what should the course of action when seeing a lot of cache misses: (a)
>>notify application team, or (b) increase cache size.
> It depends on the reason for the cache misses. There could be a loop over
> many nodes somewhere, in which case a larger cache might not really help
> (most caches are not scan resistant). There could be other reasons. But I
> don't see how the ability to configure the number of entries in the cache
> would help.
I agree that I don't have enough understanding of internal of how
caches work -- but, as I mentioned above, I couldn't quite figure out
a clean way to identify cache access pattern -- the best I could
figure out was what all existed there.


View raw message