There are some quick and easy ways to get additional power out of your Web Intelligence Processing Servers. Most customers don’t bother changing their servers’ configuration but they should. This blog will highlight some of the parameters you really should change. This is my first blog about performance tuning SAP BusinessObjects Enterprise, more to follow.
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 atleast the number CPU cores (or Virtual cores) available to it. If the machine has 4 cores then you should haveat 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.
Caching
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.
Customers real-life experiences of sharing a cache are mixed. Some customer report benefits, whilst others report issues generally around the stability of opening and viewing documents. Whilst there's no conclusive evidence, customers with issues use a network share that isn't as quick to respond as local disk. For example the latency is high (over 3 ms) and/or the disk is just slow to either create a new file, or read an existing one. So if you enable a shared cache, be careful to monitor any instability. Any issues rollback. When the 'Output Cache Directory' is left blank, then each machine will use a single cache folder for all the 'Web Intelligence Processing Server' running on it. If you like, there's always a cache that is shared, but by default only with the 'local' Web Intelligence Processing Servers. Setting the 'Output Cache Directory' to a true common shared folder means its shared more. When the 'Web Intelligence Processing Server' starts up it calculates how much cache is being used. Prior to about BI4.0 Patch 6.7 and BI 4.1 Patch 1.3, this calculation had to be completed before the process accepted work (it would say in 'initialization' status and not move to 'running'). After these releases a separate thread is doing this task allowing the process to enter 'running' state much sooner.
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.
Making changes + feedback
As with any changes you make, put them through change control so you can rollback should you get any ill effects. Having said that, I strongly believe that the above settings are pretty universal.
Adobe and Acrobat are either registered trademarks or trademarks of Adobe Systems Incorporated in the United States and/or other countries.
Windows is a registered trademark of Microsoft Corporation in the United States and other countries.
