BI Workspace on 4.1 SP4 PL4 Slow to Load

[cbethune]

I have a workspace that is used when a user logs in as the home page and it takes 1-2 min to load.  This is via a Tomcat server in the DMZ with SSL and all required ports appear open and other apps seem ok.  When accessing via internal Tomcat, also SSL, its fine.

I also traced this using Google Developer tools and it hangs on AFDashboard... components.  I thought old school Dashboard manager was dead.  Guess there are some pieces of it still around.

I found the page that was loading slowly and attempted to load in another window and it was pretty quick.  So it seems to be an issue when loading via BI Launchpad.  The properties of the workspace seem to be using the proper base URL.

I haven't found any results via Google or SAP notes that seem relevant.

Any launchpad specific settings via Tomcat I may be overlooking?  Starting to think I may be head for a support incident on this one.  Going to pour through the Tomcat logs to see if anything turns up there and maybe so an end to end trace.

The gentleman who installed the QA environment insists it was fine before PL4 was applied, the PROD environment was like this pre patch so not sure I see a relationship there, other than maybe something was off before and it got "corrected" to his disfavor with the patch.

Final tidbits of info: Windows, AD Auth (issue occurs with Enterprise too), SQL Server CMS, Tomcat Webapps redeployed multiple times to no avail, work folder also cleared multiple times to no avail.

Data folder perhaps?

This one has me stumped and there are very few issues I can't eventually track down the culprit.

Ideas?

[cbethune · Accepted solution]

Here is some updated info after further testing/troubleshooting:

I went ahead and used Fiddler instead of Google Dev tools.  Much more functionality added since the last time I used it.  Only thing maybe odd to me is that it appears that when the BI workspace goes to load is that it re-authenticates via a token but it does so successfully.  Not surprising as it seems to work kind of like OpenDoc but calls the Performance Manager application which I suspect is the remnants of old school Dashboard Manager and it wasn't worth the effort to rename everything.

Some WEBI docs are loaded but the bottleneck seems to happen before that.

So, I've asked the system admin to go ahead and execute an end to end trace and see if anything useful comes out of that.   Not sure it will ID much other than the location of the bottleneck since everything works, just really really slow.

Anyone know of any detailed info on how the BI Workspaces work behind the scenes?  Not finding anything beyond how to use the app from an end user perspective.  Curious if there is a properties or xml file somewhere that needs to be updated that isn't well documented.

Also, it seems to be slow inside the firewall as well just not quite as noticeable.  This is a multi-host environment with a high amount of CPU and memory resources and no processes are showing abnormally high utilization during the workflow in question.

This one has me really stumped!

[Henry_Banks · Accepted solution]

Hi,

I have not heard of this being an active issue, nor am i too sure if this would be considered a defect due to the qualified effect of having the DMZ firewall.

Yes, parts of the legacy AFDashboard components are still used behind the scenes.

There was a language dependent bug - German locale caused a problem on loading, resolved in the higher echelons of BI4.0 SP05

Also, on some UNIX platforms, not having the "name service cache daemon" (nscd) running can cause perf degradation. not sure if that applies to you.

Yes, i think it would be prudent to contact technical support, in case there are internal investigations on-going, or at least, to trigger the investigation process.

Best of luck. Do keep us informed

regards,
H

[cbethune · Accepted solution]

Thanks for taking a look and providing feedback.  The incident will be logged.  I do agree that it would be difficult to consider it a defect.  We will see how it goes.  I've been around the product for a long time and with things like this I still learn new things about the inner workings of the product. 

• I've provided results of an E2E trace, no errors to speak of, just really really slow
• I also provided a session recorded in Fiddler; definitely hanging on AFDashboard components
• I don't see any evidence of ports being blocked. 
• I found one note that discusses a load balancer issue but that has been ruled out
  
• Also, the load balancer in front seems fine because the internal site loads pretty quickly. 
• Only difference that sticks out to me is SSL outside and no SSL inside
• Turning off SSL didn't help though
• The Webi reports that are embedded are also somewhat slow but nothing on the same order as the Workspace
• It almost seems as if there is a circular DNS reference or something but I can't prove it
• We did observe that on a QA system the issue did not exist until patched to the same level
• Yes I know it usually goes QA then PROD but there were extenuating circumstances in this case.  The QA and DEV builds are new to get them using proper lifecycle management and get things in proper sync.
  

Any other info that anyone thinks could be of help to support?

I have debated suggesting they use another technology like a Design Studio app to serve the purpose but BI Workspaces meet the need really well in this case.

[cbethune · Accepted solution]

Unfortunately, we did get pretty much the answer that was expected out of support....that there is a network issue.  In all fairness, that would be my take most likely if I were on the receiving end of an incident.  So at this point we're at an impasse and searching for anything that might provide a clue on the root cause in order to drive at a solution.

So if anyone has any new ideas out there....please send them my way.

[former_member254640 · Accepted solution]

Hello Chris, we are facing the same issue and have not found any solution.  Were you able to resolve this?

[cbethune · Accepted solution]

We ended up replacing it with an Apache based reverse proxy server instead.  Less resources needed and only a few open ports needed.  I used the following SCN Wiki as a starting point.

Configuring the reverse proxy - Business Intelligence (BusinessObjects) - SCN Wiki

[denise_dunker · Accepted solution]

We had experienced the same issue.  Logings to Bi Launch pad for certain users were taking minutes.  After setting limits on the probe instances, the login time went from minutes to a few seconds at the most.   I think my problem was caused by having a excessive number of  instances under "My Recently Run Documents"  from Probes.  Hope this helps someone......