Performance tuning tips for BI 4.0 Web Intelligence
Hello Webi Gurus,
I have been working in support for over 15 years and have seen many grey areas that fall in between Product Support and Consulting. One of the most common grey areas is performance.
I’ve started a compilation of Tips concerning performance at the below link for more ideas.
NEW – DOC Tips for Optimizing the Performance of Web Intelligence Documents
Product Support’s main objective is to help uncover defects and provide customers with solutions for issues that impact their ability to utilize the full potential of their Business Intelligence deployment. Performance issues are tricky because they are not always related to defects and can spawn from a variety of scenarios and can occur at basically any of the tiers within the deployment. Quite often the performance bottleneck is related to configuration or process flow rather than a defects in the software.
An average install of BI 4.0 includes the following tiers that can contribute to performance issues while running reports:
- Client Tier (Workstation/Browser/thick client applications)
- Web Tier (Web Server, Load Balancer, Proxy/Reverse Proxy Server, Network)
- Application Server Tier
- BI Processing Server Tier (BI 4.0 Servers)
- Database Tier
We could probably even go deeper than those levels mentioned above but I don’t want to get too deep today as my main focus of this blog post will be the Client Tier.
Over the coming months, I will be writing up blog posts that cover a variety of tricks, tips and known issues that relate to performance at these different tiers. I will be utilizing wiki pages for the bulk of the content and will be using a series of blog posts to drive awareness of the wiki pages.
My first wiki post is up live now and can be found below.
Tips For Fine Tuning Performance For The Webi Rich Internet Applet
The above wiki page goes into detailed steps on how you can fine tune your client machines to utilize Java caching and the Java Next-Generation plugin architecture to ensure that your end-user’s load times for the Rich Internet Applet (RIA) is as quick as possible.
It also details some troubleshooting best practices and tips for identifying bottlenecks.
I’d love some feedback on this page and if anyone has anything to add, please let me know.
Thanks for tuning in (Pun intended)
Well done JB! Great way to bring some of the 'Grey' out of performance!!!
Good stuff! Looking forward to the next chapters.
this was much needed, thanks JB!
Thanks for sharing.
Good one. Thanks for Sharing JB
Very helpful information.
Just trying to get a pulse check from other -
First time the applet took more than 5 minutes but subsequently it is taking just over 2 minutes to load. Is that typical and should be expected - just over 2 minutes for the applet to load. I do understand that there are lot of other factors that can impact this time such as network connection and desktop specs, so justw anted to know on what are other folks experiencing within their environment.
I'll let others chime in on real work load times. All the testing I do is on virtual machines internally with the client and server either being the same machine, or within very close proximity. From working with other customers, I can tell you that the load times definitely vary depending on the JRE settings and the location of the client machine in relation to the server.
On my wiki page, I show how to enable the Java console tracing. That might give you an idea of where the time is being spent and if caching is being used properly. The biggest factors with load time that I have found are:
Might be worth doing a Fiddler trace of the workflow as well to see if you can isolate the delays in there as well.
Based on the great information in your wiki, I was able to establish that it is using the cache in subsequent loads and hence the reduction from over 5 minutes to 2 minutes.
In your idealized setting what kind of times are you seeing? It would help everyone to know the best they can hope for.
Thanks a lot again.
Internally I can get a 10-20 second load time. This is when the client (Browser) and server (Application Server) are co-located.
In your scenario, is the client far away from the application server? If so, perhaps you could try adding an application server to your landscape that is closer to the clients that experience these delays. This can however just move the bottleneck as now the communication between the application server tier and the BI Processing Server tier will be further apart. Might be worth a try if you have the resources available.
Awesome stuff looking forward for chapter 2
Thanks, great Blog! performance enhancement at its best!
Support never lie 😉
was there ever a chapter 2 or more? or posts on the other teirs??
No Chapter 2 yet. I've been meaning to get around to it! I'll post a link to it when I get around to writing it.
ok thanks - looking forward to it - so.... hopefully you'll get some time in the [very] near future! 🙂
Chapter 2 is coming in a different form. Working on a Top Tips for Performance document here now:
Chapter 2 is out now, and Chapter 1 (client tier) is expanded on a little.
More chapters coming in the next few weeks. I've set aside some time specifically for this.