powered by Jive Software

Why do WF extend cache size?

Cache Summary in admin console may display current WF’'s cache size,i see Roster cache already used 85%,now i want to know how extend it more size?because it is say effectiveness is low when cache too small.


Hi Tom,

You can increase the size of the roster cache by creating a system property called “cache.username2roster.size” and value of greater than 512 * 1024 (Wildfire’'s default).

However, increasing the size will not necessarily make the cache more effective, and in some cases may hurt Wildfire’'s performance because it will be using more memory. An 85% effectiveness rate is pretty good, if you have people signing on/off and adding/removing contacts cache misses are going to occur.

Hope that helps,



I wonder why you should increase it as long as it is not used 100%. Then and no minute earlier Wifi must purge old objects and if the cache is too small Wifi will purge “live” objects and not dead ones. Of course there is also a maximum object lifetime after which the object also gets purged, no matter if it is still a “live” object. So you may even think about increasing the expiration time if your user base is not increasing.


@Ryan: “85% effectiveness rate is pretty good,” … but 85% used something completely different.

Gato’'s Cache Guide:


Hey guys

i have a little confuse about WF’‘s cache function.i click “clear selected” when my User Group Cache reach on 83 Percent Used.now User Group Cache’‘s Percent Used is 0.0% and Effectiveness is N/A.i don’‘t know whether it have some effected with my WF server.Who can explain WF’'s cache process?

currently my Roster cache Percent Used 93.3% ,Effectiveness is 36.6%,moreover it’'s display a pane in cache name.it seem say ''the cache is too small. Caches for which this may be the case are specially flagged. ‘’. now Do i need extend it size?


I wonder why you should increase it as long as it is

not used 100%.

I’‘m not sure I understand what you’'re saying here. If you wanted to drive the used percentage up to 100% you could set the cache size to a really small value, say 1MB, but that would in-turn drive the effectiveness rate way down.

@Ryan: “85% effectiveness rate is pretty good,” …

but 85% used something completely different.

Yes, that’'s true.

Hi Tom,

Who can explain WF’'s cache process?

If you want a technical explanation, take a look at Cache class in the Wildfire url=http://www.jivesoftware.org/builds/wildfire/docs/latest/documentation/javado c/javadocs[/url].

The cache process basically works like the following (in the case of a user logging in):

  1. User sends a login request to Wildfire.

  2. Wildfire checks to see if the user’‘s data is present in the cache, if it isn’'t this is called a cache miss, so the user data is then retrieved from the database/ldap/pop3/etc and loads it into the cache. At this point the cache effectiveness rate is 0%.

  3. The user signs out of Wildfire.

  4. The same user sends another login request to Wildfire.

  5. This time Wildfire will find the user’'s data in the cache, so this will be considered a hit. At this point the cache effectiveness rate is 50%.

As I said, this is a really basic explanation, there is a lot more going on such as when caches expire and are flushed out or become too large and start culling themselves (again this is explained a bit more in the javadocs).

Do i need extend it size?

Take a look at this kb document for general sizing guidelines:

Hope that helps,


Hi Ryan,

I still wonder why one can set an expiration time. Only Wifi is accessing the database and if it purges all deleted or modified objects there should be no need to expire one. If it doesn’'t then even a cache duration of five minutes will cause some trouble. Whenever the cache is is too big, the l[/u]east f[/u]requently u[/u]sed elements are deleted until the cache is at least 10% empty.[/i]

After the first LFU delete is interesting to know if the cache is working effectively, so if it reaches the 97% level once again very fast one can be sure that this causes some database load.

On the other hand one may want to keep the cache size very small, so it makes sense to have the option to expire objects after some hours.


thanks to ryang and it2000,i already know WF’'s cache function,it can soared server response effectively, i should observe it occupied size,when cache used too high about 90% up,i will enhance it size.