Cache features in 2.6.x

Openfire Openfire Support
1

Hello all…

Now that we can see those cache amounts from the AC, is there some way for us to “tweak” or change their sizes (startup initial sizes or on-the-fly expanded) from somewhere?

Yeah, I figured I needed to put out an easy question sometime :stuck_out_tongue:

Cya

2

Hi Michael,

It’‘s actually been possible to manipulate the caches prior to 2.6.x but now it’‘s just a bit easier to see the changes you’'ve made in the Admin Console.

In order to tweak the cache sizes and expiration times on-the-fly you’'d have to write some code, however writing code to make changes at startup is not required. Below is a snippet of the Javadocs from the CacheManager:

The size and expiration time for the cache can be overridden by setting Jive properties in the format:

  • Size: “cache.CACHE_NAME.size”, in bytes.

  • Expiration: “cache.CACHE_NAME.expirationTime”, in milleseconds.

where CACHE_NAME is the name of the cache.

/i

The following are the available CACHE_NAMEs and where they are used:

multicast / MulticastRouter

filetransfer / ProxyConnectionManager

offlinemessage / OfflineMessageStore

userGroup / GroupManager

pop3 / POP3AuthProvider

ldap / LdapAuthProvider

userCache / UserManager

registeredUsersCache / UserManager

username2roster / UserManager

listsCache / PrivacyListManager

group / GroupManager

vcardCache / VCardManager

Manipulating the caches probably isn’‘t going to be something that you’‘ll need to do very often, such as when you’'ve written your own UserProvider, but it is nice to have access to them.

Hope that helps,

Ryan

3

Where do you adjust the cache sizes so they’'re effective at startup? My Roster cache is at 95.9% and my User Group cache is at 89.7%

Thanks!

Bob

4

Any property changes you’'ve made will be picked up during startup.

Hope that helps,

Ryan

5

Hi,

I really wonder if you get a higher efficiency by increasing the cache size. Maybe you can report if it did help.

LG

6

It’s going to depend on if cache misses (which as we all know by now lowers the effectiveness percentage ) are the result of the cache not being large enough to hold all the needed data or if the data in the cache is expiring due to non-use. If you have a lot of users it might be worth it to try increasing the cache sizes. However, if you have a small number of users you could try increasing the expiration time but I don’‘t know if I’‘d bother since performance wouldn’'t be an issue to begin with.

7

Hi Ryan,

I just did check the default cache size, 3.5 MB for all caches is not really much. And 6 hours expiration time are also not very much. For me it still makes no sense to set an expiration time for values which are stored in the database as only Wifi uses it and these objects can never exipire (unless one did write buggy code to purge objects). The lru algorithm should lead to a good effectiveness as long as the cache is not too small. But a cache which did never used more than 97% can not benefit of a larger size.

Maybe Gato want to add a counter for us do display how often cullCache() did remove old objects.

LG

8

Where do you enter the new properties?

for example, if I wanted to increase the group cache to 2mb?

9

/server-properties.jsp

… and I have no idea whether one must restart Wildfire to apply the setting.