Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jackrabbit.apache.org
Date: Thu, 13 Oct 2011 11:09:11 +0000 (UTC)
From: "Bart van der Schans (Commented) (JIRA)" <jira@apache.org>
To: dev@jackrabbit.apache.org
Message-ID: 
 <1184313953.8639.1318504151944.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <512255981.7364.1317985109744.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Commented] (JCR-3098) Add hit miss statistics and logging
 to caches
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

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

Hi Alex,

Thanks for committing!

> - no put count - I can't see a situation where #puts != #misses.
You can put an object that already exists in cache. Not sure if that's happening anywhere in the code though. It's not really a very important stat.

>  - cache manager logging to debug instead on info 
The reason why I logged it on info is to make a difference between the resize log messages (which happen every second and are quite verbose) and the stats logging which only happens once a minute by default. The "old" JR 1.x bundlecache logging was also set on INFO.

> The AbstractBundlePersistenceManager stuff will come at a later time, along with a dedicated stats object. 
That was the reason I actually created the patch ;-) The bundleCache tuning is critical for getting the optimal performance in our web based (mostly read) environments. Registering the PM as listener itself isn't the most beautiful solution I agree. For trunk we should find a better way and avoid duplicating the "log only once so often" code. Probably with some kind of CacheStats(Manager). For 2.2 it might the easiest route to just register the listener, but maybe not the best. I guess that will depend on the impact of the dedicated stats object on 2.2?

Anyway, I would love to see this in 2.2 as well!

Some very minor things: 
- shouldn't we move the  totalAccessCount.incrementAndGet(); in the recordCacheAccess() to the beginning of the method?
- for really easy log parsing it could make sense to remove the spaces in the log output, e.g. "Cache name" -> "cachename", "used memory" -> "usedmemorykb", "max memory" -> "maxmemorykb" 


> 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
>
>         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