// you’re reading...


Performance Tuning Parameters for Navigation Manager

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.

Web Site Configuration Info

The following settings are available in the main.config file in C:program filesReddotCMSASP.  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:

XmlCache – Seems to be used to cache RQL commands
PageCache – Handles navigation related pages, make this at least as big as you nav structures
PageIndexCache – As per page cache, but related to nav man’s internal indexing, make this the same as PageCache
ProjectCache – Seems to store master page setting info and language info, probably doesn’t need to be very high but make the timeouts long cause these values don’t change very often
ParserCache – Seems to cache the parse result of render spots.  This is a .Net object model interpretation of the xml instructions in a render spot.  Used by the PageBuilder, the more spots you have the higher this should be
ObjectCache – Seems to cache the resulting objects created by the object loader.  These are special .Net objects that are the result of the instruction Int:2, for example, which results in an Int32Loader object with a value of 2
SpotCache – I can’t see how this is used, there seems to be no reference to it in the code at all

Cache Behaviour Tuning

The RedDotCMSServiceProcess.exe.config file in C:program filesReddotCMSServicesObjectServer 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. 

DebugLogging – true/false – if true writes all cache operations to the CacheService.log file in the Navigation sub folder.  Be warned this will get big fast
UsePreCaching – true/false – when true the cache fetches pages further down in the tree than requested into cache to make subsequent page requests faster
MultiThreadedRendering – true/false – when true navigation rendering happens in multiple threads to better utilise hardware resources
RenderThreads – int 1 < x < 20 – the number of threads to use when rendering in multi-thread, defaults to 10, don’t overdo it
ClusterThreads – int – defaults to 4, used to control the number of threads for executing asynchronous jobs that are logged with the global ClusterManager. Again, don’t overdo it
CacheServiceTimer – TimeSpan – this is the amount of time before the cleanup task runs across the CacheManager to check whether it is within the config file tolerances
CacheTimeStampTimer – TimeSpan – this is the frequency with which cache item timestamps are updated.  If you are running cleanup every 10 minutes you probably don’t need to update timestamps every 5 seconds
CacheMonitoring – 0/1 – when 0 the CacheMemory value corresponds to the amount of virtual memory the process can consume in megabytes, when 1 the CacheMemory value corresponds to the number of items that are being held in the combined caches (basically the sum of the MaxItems in the other file ought to do it)
CacheMemory – int – either the maximum virtual memory in MB or the maximum number of cached items depending on the value of CacheMonitoring
CacheRelease – int x < 100 – the percentage of items or memory that will be released when a limit is tripped

The Cleanup Process

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.

Production Recommendations

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.

Sample Settings – main.config

  <Cache type=”XmlCache”>
  <Cache type=”PageCache”>
  <Cache type=”PageIndexCache”>
  <Cache type=”ProjectCache”>
  <Cache type=”ParserCache”>
  <Cache type=”ObjectCache”>
  <Cache type=”SpotCache”>

Sample Settings – RedDotCMSServiceProcess.exe.config

    <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″ />

Share and Enjoy:
  • Print
  • email
  • Twitter
  • Digg
  • Reddit
  • StumbleUpon
  • Google Bookmarks
  • del.icio.us
  • MisterWong
  • Facebook
  • LinkedIn

No related posts.

About the author:

Richard Hauer Richard is a Solution Architect with 5 Limes in Sydney, Australia. Richard has delivered CRM, .Net and RedDot solutions to many household name companies including Microsoft, Coca-Cola, Rothmans, Nestle, Tourism Australia, Network TEN, Australian Wool, Panasonic, the Royal Agricultural Society, Perpetual, and Challenger.


7 comments for “Performance Tuning Parameters for Navigation Manager”

  1. Great article, I wonder if this will be the same with version 10?

    Posted by Markus Giesen | June 3, 2009, 1:05 pm
  2. Even though we do not use Nav Manager in our projects, RD have recommended we review these settings. Do you think this in general relates to overall page performance as well even if Nav man is not directly used? (We use render tags)

    Posted by BjP | June 4, 2009, 12:35 pm
  3. @Markus From what I have seen these parameters still exist and they have added a few more to boot. The PageBuilder is now a proper .Net Windows Service component (instead of the COM+ component it is today) which gives it access to a modern environment’s multi-threading capabilities, but still retains much of its internals and therefore is properly backwards compatible.

    I have heard talk of a separately available “performance kit” that will deploy the v10 PageBuilder on a v9 CMS which will be great.

    Posted by Richard Hauer | June 5, 2009, 12:53 am
  4. @BjP I am using NavManager and Render Tags a bit interchangeably here. If you’re not using the navigation-related Navigation Manager components (the tree, areas and templates) you will not make use of the Page and Element level-caching but you will still use the XmlDocument and spot caching, so while these parameters will have a less dramatic impact on performance it is still worth spending some time to get it right.

    Posted by Richard Hauer | June 5, 2009, 12:57 am
  5. Hi,

    great article!

    But one question: Do I have to change these settings on a server with more and bigger projects ? We run one project with 80000 pages/18 language variants and 20 smaller projects with one language variant per project.


    Posted by Michael Volkmar | June 10, 2009, 1:02 pm
  6. I’d say just give it a try … if the performance increases without any side effects, it’s ok. Otherwise decrease the values gradually.

    Most important thing about RedDot / Open Text Management Server is experience, as projects tend to be quite differen from customer to customer. If you’re playing with these settings, please tell us about the results!

    Posted by Frederic Hemberger | June 18, 2009, 7:08 pm
  7. The settings are global and not per-project so you will need to size based on aggregates (the sum of all the projects). Essentially, the caches are shared across projects.

    Update: I have run into a little problem where the RedDotCMSServiceProcess.exe process gets itsef stuck in a loop (at least that’s how it appears) and it seems to be the combination of pre-caching and hitting the cache limiters (precache-dump-precache-dump-precache-dump etc). I’ll attach a debugger next time I catch it and post an update on what to avoid – for now restarting the Object Service is sufficient.

    Posted by Richard Hauer | June 23, 2009, 2:34 pm

Post a comment

Stay up to date! - Get notified about followup comments

If you don't feel the urge to comment but wish to stay in the loop:
Just enter your email and subscribe to new comments.

Subscribe without commenting

Recent Tweets

  • RT @AirKraft: Transport Canada breakout: they manage 80K pages and 300K assets with WSM(RedDot). Wow! #OTCW 2010-11-11
  • The RedDot usergroup session 'Future of WCM' is in National Harbor 7, now. See you there! #otcw 2010-11-11
  • RT @yttergren: @AirKraft: Calling all WSM(RedDot) devs: share your solutions on http://bit.ly/bgPIof EVERY solution can win an iPad #OTCW 2010-11-10
  • Come to the Solution Exchange session. Enhance your (#reddot) CMS project! Chesapeake 12, 3:20pm #otcw Looking forward to see you there! 2010-11-10
  • More updates...