Performance Tuning Web Intelligence Processing Servers

Posted: July 14, 2011 in Business Objects, SAP, Web Intelligence
Tags: ,

Number of instances to run

To benefit from maximum scalability, set the number of instances of this service within a machine (or virtual machine) to be at least the number CPU cores (or Virtual cores) available to it. If the machine has 4 cores then you should have at least 4 instances of Web Intelligence Processing Servers running. This is a golden rule not to break!

One ‘Web Intelligence Processing Servers per CPU core per machine’ also helps with load balancing. Let’s say you have 2 machines, one machine of 4 cores, and another machine of 2 cores. You’ll want the 4 core machine to receive twice as much Web Intelligence ‘work’ as the 2 core machine.  To do this you just allocate twice as many Web Intelligence Processing Servers to the 4 core machine compared to the 2 core machine.  And if you follow the one ‘Web Intelligence Processing Server per CPU core per machine’ rule, that’s exactly what end up with! Perfect.

Maximum Connections

Sometimes, however things are not so straightforward and you want a bit more fine tuning without breaking the golden rule “One Web Intelligence Processing Server per CPU core per machine”. For example when the ‘power’ of your machines isn’t determined by the number of CPU cores, but by something else like faster CPUs, what do you do then?  This is when the Web Intelligence Processing Server property ‘Maximum Connections’ should be used to ‘balance’ the load.  Let’s say you have 2 machines, both have 4 cores, but one machine runs at 2.0 GHz and the other at 2.5 GHz (25% faster). You want the 2.5 GHz machine to receive 25% more ‘work’ than the 2.0 GHz. Simply by increasing the ‘Maximum Connections’ for each Web Intelligence Processing Server on the 2.5 GHz machine by the required ratio will result in the load balancing to be weighted towards the 2.5 GHz machine. In this example we would increase this parameter from 50 to 63 (50 + 25%= 62½, round up to 63). Don’t be tempted to reduce this figure, as if there aren’t enough connections a user will get “server busy” messages. You don’t want to add unnecessary software limits on your hardware resources. There is a school of thought that you should drop this parameter to ‘protect’ the server, I don’t follow that school, and would prefer to let the server do as much as it can, potentially giving a slower response time when busy, rather than generate an error when it’s not busy at all.


There are many wonderful ways to configure the cache to suite your environment. Let’s have a look at the main cache properties on the Web Intelligence Processing Server one by one:

The property “Enable Document Cache” is correctly enabled by default, make sure it stays enabled.

Document Cache can have a very significant performance improvement as experienced by end users. This feature, when enabled, allows a Web Intelligence Job to ‘prime the cache’. The cache is primed when a Web Intelligence job is run, as scheduled, and the presentation view (Microsoft Excel®, Adobe® Acrobat® and HTML, but it’s actually XML) is also generated as part of the job, though the down side is the job will take longer to complete. The cache is generated after the document has been refreshed and in the chosen formats selected.  When scheduling a Web Intelligence document it is important that the cache option is selected to benefit from this feature.  Enabling this feature can provide significant performance improvements.

The property “Enable Realtime Cache” is correctly enabled by default, make sure it stays enabled. 

Realtime Cache also has significant performance improvements when enabled. Realtime cache allows the cache to be loaded dynamically. When something is not found in the cache, it is calculated and then saved into the cache for later re-use. This applies for scheduled as well as non scheduled documents.

The “Maximum Document Cache Size”, the default settings is 1048576 K Bytes, or 1 G Byte.

This is typically quite small for most organisations. With a cache size of just 1 G Byte it will not take long for a document that is in cache to be pushed out of cache. This will mean users could experience a good performance one minute and slower the next. I recommend increasing this size significantly. A cache size of 20 GB or even 50 GB is not uncommon. Confusingly the ‘Maximum Document Cache Size’ really isn’t the maximum size, the product doesn’t check, every time its writes a file to cache, the size of the cache! This parameter is used just as a value when the clean-up route runs.  Estimate the amount of cache by clearing out the cache and seeing how much disk space is consumed once a number of documents have ‘primed’ the cache (see above about ‘priming’ the cache).  Carefully monitor the disk space after making such alterations! You don’t want to run out of disk space.

The “Document Cache Duration”, the default setting is 4320 minutes, or 3 days.

This means the cache for a given document is valid for 3 days, which is ok if your documents are scheduled at least once every 3 days. But if you’ve got weekly or even monthly documents, then you should consider increasing this duration to a week or a month, otherwise you won’t be reusing perfectly valid cache content. You want to avoid any extra regeneration of cache as possible.  If most of your documents are scheduled weekly, then a setting of about 8 days would be appropriate. The server is never going to provide a user with cache content that is invalid or out-of-date.

The “Document Cache Clean-up Interval (minutes)”, the default setting is 120 minutes, or 2 hours. (The ‘properties’ page incorrectly says “(seconds)”)

This is how often the process will scan its cache and reduce the size of that cache if it’s too large. It will delete the oldest files first, and reduce the total amount of space to ‘Maximum Document Cache Reduction Space % of ‘Maximum Document Cache Size’ (or 70% of 1 GB with default settings).

So the cache is reduced to a % size of the maximum. Thus when you are determining what the Maximum Document Cache Size should be, you need to add on a fair bit as only 70% of it will kept after a clean-up.

There’s no harm with a short setting (2 hours), but you could probably increase this dramatically if you have plenty of disk space and aren’t worried about the cache size growing well over its limit.

Sharing the Web Intelligence cache across multiple machines. Not set by default.

There’s not much point in each Web Intelligence Processing Server having its own cache when you can share. Sharing a cache has huge benefits; it means one Web Intelligence Processing Server can re-use the cache generated by another. And if you’re ‘priming’ the cache then this is even more important to gain from that extra effort your jobs are performing.

To share the cache the Web Intelligence property ‘Output Cache Directory’ should be set to a shared cache folder, typically hosted on network storage device which is accessed via a UNC or NFS path. You’ve probably already got a network file share for the File Repository Server (FRS) file store. Why not just add another folder onto that share for the Web Intelligence document cache. Set the ‘Output Cache Directory’ property to it. (If running on Microsoft Windows you’ll need to make sure the Server Intelligence Agent is running as a user who has network access).  Sharing the cache across machines can provide massive performance improvements, but watch out for network or disk bottlenecks. If you really want to get the most throughput, which might be important if you’re ‘bursting’ lots of documents via a publication, enable a network share and a separate disk system for each of: Input FRS, Output FRS, Web Intelligence Document Cache.

The “Universe Cache Size” the default value is 20 universes.

Universes that are pushed out of cache will require extra processing which is unnecessary. Set this to at least the same number of universes you have, or even a few more! It’s only a tiny bit of extra disk space and setting this to a large value won’t affect the amount of RAM consumed.

  1. learner says:

    Hey good technical document, Thanks you.

  2. dubay says:

    Hi Dhigtana, where do you get this information from? i’ve search in some documentation but returns me to this awsome blog. Thanks

  3. Gazebo says:

    Hi! Thanks for the article, it’s really very helpful. I have two questions concerning it: in the documentation, it says that the Max. Document Cache Reduction Space is the percentage _by which_ the cache is reduced, i.e. only 30% of the data would stay in the cache. From your article I read it the opposite way. Which is correct? and second: the “Maximum Documents in Cache” is set to 0 by default. Does that mean that it uses only the maximum size or the number or when would I need this? The Admin guide is not overly helpful… Thanks again and keep up the good work!

  4. malik says:

    Can someone explain me what is Cache Timeout In Server Properties in Business Object Central Management Cosole. Does it have anything to do with WEBI Report timeout.? Thanks

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s