We have 2 Webi servers in a cluster with 4 CPUs each. However, when we run a large report (whether through BCA or in full client on the server), we notice that the busobj.exe process maxes up only one of the CPUs on one of the servers, while all the other 7 CPUs remain idle. Also, the database server is not doing anything while the report is “hogging” that one CPU. As a result, the report takes a lot of time to run. So, here are the questions:
Why does the busobj.exe process “churn” CPU cycles for such a long period of time (as much as 15 CPU minutes for one report!), after getting the data it needed from the database server (which happens fairly quickly)?
If that’s inevitable, can the busobj.exe process be configured to multithread a single report over the several CPUs on the server?
Are there any other performance tuning options that can be changed to improve performance of CPU-intensive reports, given that database queries do not seem to be the bottleneck?
Thanks in advance for your help!
Celso
P.S.: if you do provide this type of work (BO performance tuning) professionally, please let me know, we may need your professional assistance here…
It is processing the data that was returned. If you have a large number of variables, or a large number of data providers, or even variables using “high overhead” functions this is not unusual.
No, not at this time. I don’t believe that BusinessObjects coded the busobj.exe to be multi-threaded.
Before the onslaught begins, let me remind everyone of the no advertising policy here on BOB. If you have used a service provided by another company / vendor you may comment on that. But vendors cannot recommend themselves. CMELLO, you may want to ask folks to email you directly if offering their services rather than posting here on the forum. Thanks.
What you’re seeing is actually common BO behavior. One query will typically spike a CPU (whether on the desktop or a server), but the 100% CPU usage doesn’t seem to be an accurate reflection on performance. For example, if we run two reports on one of our Citrix servers (2 CPUs), both CPUs spike to 100%. However, these servers have been load tested refreshing 25 reports simultaneously w/o any degradation in performance. So, even though the computer says the CPU is at 100%, it doesn’t necessarily mean that performance is impacted.
In your situation, I’d document the query time (through the data provider utility) vs. the wall clock time (actual elapsed time for the report to return). If the query time is definitely not the problem, then BO’s taking a lot of time performing calculations and displaying the information. One way you can test this is to make a copy of your report and replace the report tab(s) with a blank report. Now compare the run times of the two reports to see if it’s actually the display portion that’s churning up the CPU.
On the report level, complex calculations and hard-coded formulas (i.e. a different formula for each cell) can increase the time it takes BO to render a report. If the query is returning many rows of data, this issue will only get worse.
Another thing to look at is to ensure you’re retrieving data at the appropriate grain. For example, if don’t need to go down to the lowest level of detail for reporting purposes, it’s often faster if you can bring in summary level data.
As far as I know, BO is not multi-threaded, but here is a good link on multiple CPU discussion:
Thank you very much, Dave and DJ, for your replies. It’s all very useful information and will allow me to make more educated choices when getting reports designed over here (for instance, I learned from this that I should stay from calculations on the report and try to do that in the ETL if I can).
And Dave, I do apologize for my comment about professional services - I should have read the policy before. Sorry.
(BOB member since 2003-11-24)
CMELLO, you may want to ask folks to email you directly if offering their services rather than posting here on the forum. Thanks.
(BOB member since 2002-06-06)