Tuning the "More" Cache

We all know the pesky little "More" command that lets you download successively more and more of your email, beyond the first 4K delivered to the BlackBerry.

Well on the server side, there is a cache that holds this information, and it is called the "More cache". [Wow these names really need a little obfuscation, they make too much sense to exist in the PC world]

Anyhoo, you can tune the amount of cache that the BES allocates to this function, and by default it gives it 10MB. Well at this level I was filling up the cache in about 6 hours from server startup, and only realizing a maximum of 84% hit rate:

[45009] (09/14 02:35:58.078):{0x13BC} More cache hit rate: 0.0%, requests: 0, adds: 0, size: 0.0/10.0 Mb
...
[45009] (09/14 08:33:32.778):{0x13BC} More cache hit rate: 69.0%, requests: 126, adds: 2270, size: 5.7/10.0 Mb
...
[45009] (09/14 09:48:32.294):{0x13BC} More cache hit rate: 75.7%, requests: 214, adds: 5031, size: 10.0/10.0 Mb
...
[45009] (09/14 23:48:32.111):{0x13BC} More cache hit rate: 84.4%, requests: 784, adds: 29120, size: 10.0/10.0 Mb


If the remaining text is not found in the More cache, then the BES server needs to open the mailfile to pull it in, which is expensive in terms of network I/O and Domino server I/O. [Not hugely, of course, but I like to squeeze as much performance out of my systems as possible] If it can find it in the cache, here is what you will see in your MAGT log:

[40231] (09/14 01:11:01.290):{0x608} {XXXX} Original message (RID=-576019096) retrieved from More cache. Not opening the mail file.

That is a message that I like to see!

So I decided to double the default of 10MB to 20MB by adding the following DWORD registry key, and setting it to "20" decimal:

HKLM\Software\Research In Motion\BlackBerry Enterprise Server\Agents\MoreCacheSize


After a restart of the server (not required) here is what I now see:

[45009] (09/20 13:50:51.888):{0x14E0} More cache hit rate: 89.5%, requests: 3004, adds: 127078, size: 20.0/20.0 Mb

So fully loaded, it is running ~90% cache hit rate now, which is not a huge gain but it is something. RIM considers >90% hit rates to be good, but I haven't decided how much more I want to push this setting as it takes away memory from other processes for this task.