In CMS 7.5 Service Pack 2 a number of new cache tuning parameters were introduced into the Navigation Manager services. These are primarily controlled by settings in a few of the configuration files. I am going to talk briefly about what they do.
Side note: When changing these values I recommend restarting IIS and all the RedDot branded Windows Services to ensure the changes take. There is a lot of inter-process communication going on and it’s best to make a clean start.
The following settings are available in the main.config file in C:\Program files\RedDot\CMS\ASP. For each of these settings there are 2 values, MaxItems and Timeout. When the cache cleanup process runs (at the interval specified in the other configuration file, more info below) each of these cache groups gets culled back using the parameters configured. Timeout is used to age an item out of cache, think of it as an expiry time, and MaxItems is a headroom limit on the number of items that can be held in the cache. When the MaxItems value is reached the CacheRelease process is triggered (again more later) which reduces the count by removing items in the order of least recently referenced to most recently referenced (i.e. it leaves items you used most recently in the cache).
What is not clear is precisely what items are being cached where. If I figure this our better I’ll update the post, but I do know the following:
The RedDotCMSServiceProcess.exe.config file in C:\Program files\RedDot\CMS\Services\ObjectServer contains behavioural instructions that are loaded into the global CacheManager objects using a process called .NET remoting (this is how the RedDot Windows Services can share objects). The <appSettings> in this file are pushed onto the CacheManager when the RedDot Object Service starts.
Every <CacheServiceTimer> period the cleanup process checks each of the caches listed in the main.config to see if it has blown its imposed lifespan of size limit. If so items that were "touched" the longest ago are released from cache such that only (100 – <CacheRelease>)% items remain. This same process checks the <CacheMonitoring> value to see if a global limit has been reached with the same consequences.
For the most part I’d leave the thread settings at the defaults but turn the MaxItems and Timeouts right up because they relate to information in the templates which is not content, and therefore not very likely to change. I have included the settings I am using on a 2000-page 4 language site below.
Remember that on a 32-bit machine a single process can have no more than roughly 1.2GB of memory allocated to it due to addressing restrictions, no matter how many threads you assign. More threads means more work which slows down other threads and causes memory to be paged out to disk, resulting in dramatically reduced performance.
<Caching> <Cache type="XmlCache"> <MaxItems>50000</MaxItems> <Timeout>01.00:00:00</Timeout> </Cache> <Cache type="PageCache"> <MaxItems>10000</MaxItems> <Timeout>01.00:00:00</Timeout> </Cache> <Cache type="PageIndexCache"> <MaxItems>10000</MaxItems> <Timeout>01.00:00:00</Timeout> </Cache> <Cache type="ProjectCache"> <MaxItems>5000</MaxItems> <Timeout>07.00:00:00</Timeout> </Cache> <Cache type="ParserCache"> <MaxItems>50000</MaxItems> <Timeout>4:00:00</Timeout> </Cache> <Cache type="ObjectCache"> <MaxItems>100000</MaxItems> <Timeout>00:20:00</Timeout> </Cache> <Cache type="SpotCache"> <MaxItems>5000</MaxItems> <Timeout>00:00:20</Timeout> </Cache> </Caching>
<appSettings> <add key="DebugLogging" value="false" /> <add key="UsePreCaching" value="true" /> <add key="MultiThreadRendering" value="true" /> <add key="RenderThreads" value="10" /> <add key="ClusterThreads" value="4" /> <add key="CacheServiceTimer" value="00:30:00" /> <add key="CacheTimeStampTimer" value="00:01:00" /> <add key="CacheMonitoring" value="1" /> <add key="CacheMemory" value="300000" /> <add key="CacheRelease" value="30" /> </appSettings>