CRX Bun­dle Cache caches bun­dles, con­sist­ing of a node with all its prop­er­ties. It is used by all bun­dle based Per­sis­tence Man­agers. The default size of this cache is set to 8 MB which is a part of allo­cated JVM heap. If an item is not found in the cache, it is read from the per­sis­tence layer.

 How­ever, default bun­dle cache size may not be opti­mized for per­for­mance in some sce­nar­ios. Hence, few tests should always be done to find out bun­dle cache size which suits your appli­ca­tion. This can be analysed from miss to access ratio of the bun­dle cache which is cap­tured in the error.log file as follows


cachename=crx.defaultBundleCache[ConcurrentCache@4b48638], elements=1987, usedmemorykb=4141, maxmemorykb=8192, access=27940, miss=19870

The above exam­ple shows an entry that indi­cates that cache was hit 27940 times. Out of this, for 19870 times, items were not found (missed) in cache and had to be fetched from the per­sis­tence layer. This is an exam­ple of high miss to access ratio of 0.71. Nor­mally, lower the miss to access ratio, bet­ter is the per­for­mance. Hence, in such cases where ratio is high, one should increase cache size from 8 MB. How­ever, one should NOT assign huge mem­ory to bun­dle cache size either as this would impact the over all appli­ca­tion per­for­mance. In inter­nal tests, we found this bun­dle cache size value, some­where near to 1/10th of JVM max heap size, gives best results. But this could dif­fer for var­i­ous sce­nar­ios (Read Heavy vs Write Heavy).

In CQ 5.5, apart from error.log, bun­dle cache can also be mon­i­tored from JMX MBeans. In order to do so, one can access fol­low­ing URL:


There are a num­ber of MBeans of type Time­Series which can pro­vide infor­ma­tion on cache usage, access, miss etc. This data can be uti­lized in deter­min­ing usage trend of bun­dle cache.

Bun­dle cache size can be changed from repository.xml and workspace.xml using fol­low­ing tags:

<Per­sis­tence­M­an­ager class=“”>

<param name=“bundleCacheSize” value=“256”/>