Skip to Content

Enabling auditing can have effect on the performance of BusinessObjects Enterprise. The impact of enabling auditing should be small, although if you enable all auditing across your deployment there will be a performance consequence as the CMS service processes the auditing event files and writes them to the BI platform auditing database. The auditing database can also quickly grow to be very large if you enable all auditing. A good starting point is to begin with CMS service auditing and then enable other services as/if required and you have evaluated the performance impact on your deployment landscape. With auditing enabled you can further optimize system performance by fine-tuning these options:


• AuditInterval minutes , where minutes is between 1 and 15. (The default value is 5.) The CMS requests auditing records from each audited server every auditing interval.

• auditMaxEventsPerFile number (number has a default value of 500 and must be greater than 0). The maximum number of records that an audited server will store in a single auditing temp file. When this maximum value is exceeded, the server opens a new temp file.


The Auditinterval is added to the CMS servers properties from the CMC in the command line parameters. Ensure you do this for all CMS servers in your cluster. You can see in the image below I like to keep my Auditinterval at the minimum value of 1 minute to ensure my Audit Database is as current as possible. (Note my system is not busy, so I prefer to have timely audit data, see below).


  audit interval


You can also change the number of events per file value from the individual servers ‘audit events’ page from the CMC. Temp files remain on the audited server until all records have been requested by the CMS.


Changing each of these options has a different impact on system performance. For example, increasing the auditing interval reduces frequency with which the CMS writes events to the auditing database. Decreasing the audit interval increases the rate at which records are moved from the auditing temporary files on the audited servers to the auditing database, thereby decreasing the length of time that it takes these records to get transferred to the central auditing database. Increasing the maximum number of auditing events stored in each auditing log file reduces the number of file open and close operations performed by audited servers.


You can use these options to optimize auditing performance to meet your needs. For example, if you frequently need up-to-date information about audited events, you can choose a short auditing interval and a large temporary file size. In this case, all auditing records are quickly transferred to the auditing database, and you can always report accurately on the latest audited events. However, choosing these options may have an impact on the performance of BusinessObjects Enterprise.


Alternatively, you may only need to review auditing results periodically (weekly, for example). In this case you can choose to increase the auditing interval, and to decrease the number of auditing records in each batch. Choosing these options minimizes the impact that auditing has on the performance of BusinessObjects Enterprise. However, depending upon activity levels in your system, these options can create a backlog of records stored in auditing temporary files. This backlog is cleared at times of low system activity (such as overnight, or over a weekend), but means that at times your auditing database may not contain records of the most recent audited events.

To report this post you need to login first.

Be the first to leave a comment

You must be Logged on to comment or reply to a post.

Leave a Reply