Skip to Content

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)

Jonathan

To report this post you need to login first.

16 Comments

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

  1. Vineet Gupta

    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.

    (0) 
    1. Jonathan Brown Post author

      Hi Vineet,

      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:

      1. Cache files are not being used for some reason
      2. Online certificate validation is turned on for the JRE (forces it to go out to a verisign website to validate each jar’s signature)
      3. Slow network connectivity between the client/server (we still need to check each locally cached jar file against the server version so there is back and forth over the network for all jars.

      Might be worth doing a Fiddler trace of the workflow as well to see if you can isolate the delays in there as well. 

      Thanks!

      Jb

      (0) 
      1. Vineet Gupta

        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.

        (0) 
        1. Jonathan Brown Post author

          Hi Vineet,

          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.

          Thanks

          Jb

          (0) 
    1. Jonathan Brown Post author

      Hi Roseann,

      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.

      (0) 
        1. Jonathan Brown Post author

          Chapter 2 is coming in a different form.  Working on a Top Tips for Performance document here now:

          http://scn.sap.com/docs/DOC-58571

          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.

          Thanks!

          Jb

          (0) 

Leave a Reply