jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bart van der Schans (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (JCR-3098) Add hit miss statistics and logging to caches
Date Fri, 07 Oct 2011 14:41:29 GMT

    [ https://issues.apache.org/jira/browse/JCR-3098?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13122835#comment-13122835
] 

Bart van der Schans commented on JCR-3098:
------------------------------------------

Hi Alex,

> You are right. The CacheManager does call reset on it. It is weird that this behaviour
is tied to a listener implementation. For example, on the patch, the AbstractBundlePersistenceManager
never calls reset. 

Yep. The reset call is only needed for correctly calculating the new cache sizes that are
managed by the CacheManager. The BundleCaches are not managed by the CacheManager and "just"
use the ConcurrentCache.

> What we could do is to only update the hitCount when the cache listeners are called,
this way we'll increase once every CacheAccessListener#ACCESS_INTERVAL (127) calls. The stats
can be a bit behind, that should not be a problem. 

I would only go for such "optimizations" if there is a need for it. Afaik the AtomicLong.incrementAndGet()
should be "fast enough". If not, we can always have a look what the exact bottleneck is and
optimize for that. For now it feels like it would only make things more complex. 

> About the element count: I feel we could leverage AbstractCache#recordSizeChange(), it
appears that when it is called with a pozitive value it's an add, otherwise it's a remove.


Ah, I missed that one. It would fit the "pattern" of the other stats. Otoh, the number of
segments is coupled to the number of CPUs (did somebody actually benchmark if that's optiomal?)
and looping over the segments should be pretty cheap.

> I wasn't talking about a dedicated CacheStats object either. I'm working on a dedicated
PersistenceManagerStat that also contains some cache info. I agree about being able to tune
the logging for a dedicated cache. 
(I'm also looking to add average cache miss duration on the PM. This is also something to
watch out for.) 

I don't think the cache miss duration is of much interest, but the time it takes to load a
bundle when the cache is missed certainly is ;-) (it's however not a statistic of the cache
in the pure sense)

> Given that we agree on the direction of the patch, we can apply it on the jmx branch,
and we can continue there the dev. This will also allow others to chime in with some feedback
before we merge to trunk. 
> I don't think I have time today, but I have to push some code related to it soon, and
I could merge your changes beforehand. What do you think? 

That would be great! I hope to have some cycles to look at the branch in the next few days
and see if we can expose the stats through JMX.

Bart






                
> Add hit miss statistics and logging to caches
> ---------------------------------------------
>
>                 Key: JCR-3098
>                 URL: https://issues.apache.org/jira/browse/JCR-3098
>             Project: Jackrabbit Content Repository
>          Issue Type: Improvement
>          Components: jackrabbit-core
>            Reporter: Bart van der Schans
>             Fix For: 2.2.10, 2.3.1
>
>         Attachments: cache-stats.patch
>
>
> The current caches (ConcurrentCache) doesn't maintain hit and miss statistics. This makes
it very hard to know if you need to increase the caches in a deployment. This functionality
does exist in the 1.5 and 1.6 branches, but is missing from the 2.x branches. The patch adds
these statistics and adds logging on info level. The frequency of the logging is by default
configured to maximal once a minute but can be configured with the system property "org.apache.jackrabbit.cacheLogStatsInterval"
(in ms). 
> The log lines look like:
> 07.10.2011 09:00:39 INFO  [org.apache.jackrabbit.core.persistence.bundle.AbstractBundlePersistenceManager.logCacheStats():737]
name=defaultBundleCache[ConcurrentCache@54fb02fd] num=21074 mem=34504k max=65536k hits=93352
miss=21074 puts=21135
> 07.10.2011 09:00:40 INFO  [org.apache.jackrabbit.core.persistence.bundle.AbstractBundlePersistenceManager.logCacheStats():737]
name=versionBundleCache[ConcurrentCache@47b1de1a] num=10637 mem=250k max=8192k hits=36352
miss=10637 puts=10637
> This patch will also make possible to later on expose these statistics over JMX when
the initial JMX work has been settled.  

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message