CMS Tuning: ndbqthreads or Number of Requested Database Connections

If you are interested in maximizing the performance of your system please review this article and also its companion: CMS Tuning: maxobjectsincache and MaximumObjectsToKeepInMemory.

Observing/Measuring Tuning Impacts

The parameter discussed in this article requires more tuning and closer observation than other CMS Tuning technique may require. I highly suggest that you do a load test and that you have a serious discussion with your DBA on tuning this parameter.

CMS Database Connections, a.k.a. ndbqthreads

The number of requested database connections is another place you might improve performance. This setting is one that will only improve performance at times of high load on the CMS. It prevents your CMS’s number of connections to its database (a.k.a. CMS InfoStore, metadata repository; don’t confuse this with report data source connections) from becoming a bottleneck to your system. It opens more conduits between the CMS and the CMS’s database. This setting will be limited by the number of connections that your CMS’s database accepts, so be careful not to exceed that number (this is something that a DBA or DBA tools can help determine. This setting is controlled by different parameters depending on your version of Business Objects Enterprise:

BO XI 3.1: System Database Connections Requested (CMC Property)

In Business Objects XI 3.1 you will find in the properties of the CMS (CMC > Servers > Your_CMS > Properties) a parameter/setting named “System Database Connections Requested“. This setting is set to “14” by default. I have heard that 99 might be the maximum, but your database’s configuration will probably restrict you before you reach 99.

A Quick CMS DB Thread Sizing Calculation

A recommended baseline is to have one connection for every 20 expected peak concurrent users. I am not speaking of the “Concurrent User” versus “Named User” user type, but I am speaking of the max number of users that you expect to access the system concurrently at any one point in time. Take this number and divide it by 20. Now take that number a divide it by the number of CMS that your cluster is running. The final number is the value that you should put in the “System Database Connections Requested” parameter value of each CMS in the cluster. This a good baseline for you to begin testing (testing this one can be elusive and will certainly require DBA skills to detect the activity on all open connections). If the per CMS number you calculated is less than the default 14 then you could reduce this setting and test for any effects; you consume less database connections which other applications or processes might appreciate.

XI R2: ndbqthreads (CMS Command-Line Parameter)

In XIR2 there is this thing called NDBQ threads. According to the Administrator’s Guide the setting exists in BO XI 3.1 as well (although I don’t understand how it plays/conflicts with the “System Database Connections Requested” setting there). The setting is made in the CCM on the command line for the CMS. That parameter is specifically “-ndbqthreads #“. I believe that “2” is the default setting and I know that “10” is the maximum (even in XI 3.1 go figure). This can be sized with the same calculation given above, but your limit will still be 10. Given this limit, some Business Objects administrators will choose to add a CMS to the cluster just to be able to add more CMS DB Connections to the cluster. It is possible that the limit of “10” does not apply to Business Objects XI 3.1 as the Administrator’s Guide states. It certainly would not be the first error/omission in the guide.