Performance tuning of any web application can be a challenge and SAP BusinessObjects tools are no different. I will share some of our lessons learned regarding xCelsius. The same approach can be applied to the other web tools as well.
Quick background: Over the last year we have been moving from a SAP BW shop using the SAP BW Delivery Tools to a SAP BW shop using SAP BusinessObjects as the Delivery Tools. We are making great progress and learning a lot.
One of the first key deliverables tied to our SAP BusinessObjects foundation project was to deliver an Executive Dashboard using xCelsius. The data sources are SAP BPC on MS SQL Analysis Server, Oracle DB, and SAP BW. We decided for performance reasons that we would schedule the WEBIs and use Live Office connections to ensure good performance. But we found there was much more to learn. Also, I believe by using a tool like HTTPWATCH we uncovered behaviors that many would not expect.
What are some of the many pieces to consider:
- How is the Vintela SSO responding
- How long does it take to download the SWF
- How long does it take for the SWF to execute after the PC receives it
- How long does each connection take
- How many pararell processes can I have/should I have
- How will browser caching help
- How will compression of
web content help
- Can I group my connection to improve user expertise
How to use HTTPWATCH to investigate your response time?
- Clear your browser cache, turn on trace, execute, then study the no cache response time
- Close all browser sessions, do not clear your cache, turn on trace, execute then study the cached response time
- If you are a shop with employees across the Wide Area Network (WAN), get access to Remote Desktop to a workstation at a remote location, install HTTPWATCH (or equivalent) on that workstation and run a no cache and cached trace.
What did we learn by see the details of the HTTPWATCH trace?
- We found multiple improvement opportunities for Vintela SSO by using Remote Desktop. Not an issue for local users. OSS 1544504 - Login to InfoView using Vintela very slow
- Get an accurate timing for SFW downloads across the WAN. Challenged us to determine the proper browser cache length of time (expire).
- Showed the amount of time between SWF being available to the browser and actually kicking off the connections. Different PCs process faster than others.
- We found many questions regarding the connections
- If you have one WEBI with 4 blocks, set up 4 connections one per block, you actually execute all 4 blocks 4 times. That may be obvious to you veterans but we were thrown off.
- So having several&nb
sp;WEBIs with only one block per connection greatly reduced our response time. In our case, it cut the response in half.
- Next IE 6 will run 2 threads at once and IE 8 will run 6 threads at once. So one would think that having your connections running in pararell would be faster. Currently our finding are this is untrue. After raising this issue we were told best practice is to force your connections to run sequentially. This finding shaved another 10 seconds off our response time. I still do not fully understand why and I do not like having to do these unnatural steps but it is worth it.
There is much more that could be said regarding tuning techniques with HTTPWATCH such as the number of return code 401s, 304s, etc... but I think I will stop for now. We used these same techniques for finding tuning opportunities for WEBI, Infoview, Explorer, etc...
This is my first time sharing via a blog. I hope you could find some useful tips. If you want to try this techniques there is a free version of HTTPWATCH available (www.httpwatch.com).
I would love to hear your lessons learned and if you think any of these findings are false. Let's discuss.
Below is a HTTPWATCH trace of an xCelsius dashboard where you should be able to see some of what is described above. It will be easier to read if you select view full image.
Jeff Duly Senior Enterprise Architect (twitter:@jlduly)