We're an international logistics corporation and have developed a Customer Facing portal to provide Supply Chain Visibility to our customers. A WebFocus8 Key Performance Indicator (KPI) Dashboard is the centerpiece of the portal.

The KPI Dashboard is very slow to render, which has our customers quite upset. We've isolated the 2 files that cause the longest delays: wfbiportalrun.jsp and views.bip. They're taking about 7 and 8 seconds respectively to download (15 seconds total). They're not big files, around 20Kbytes each, so we're struggling to understand what's going on. As I mentioned, our customers are vociferously complaining and we need to really speed this up.

Does anyone know how to speed up the downloads, and/or force them to be cached in the browser?

thanks!
EK

This message has been edited. Last edited by: <Kathryn Henning>,

I dont think its those files what are loaded but something else. I assume KPI dashboard is filled with charts? Have you tried debugging it with Fiddler?

It will show what traffic is there when page is loaded.

Also what version of WF8?

Yes the dashboard is filled with several charts. We're using the F12 key in our browser to watch the downloads. I understand that it could be a different file that's causing the delay, but we should be able to see that via the F12 key, correct?

Eric,

Yes, the network tab in the Developer tools on a browser will allow you to interrogate the network traffic and understand which calls are taking longer then others. In those 7 - 8 seconds though, WF is probably logging the user in, checking their Authorizations and performing whatever other session setup activities need to occur. If you don't need those things to occur, maybe you should consider sending the client directly to the page, and not through the portal. You can construct the call something like this :

quote:

'localhost:8080/ibi_apps/WFServlet?&|IBIMR_action=MR_RUN_FEX&|IBIMR_sub_action=MR_STD_REPORT&|IBIMR_fex=' || &DOMAIN || &SR_FOLDER || &REPORT_NAME

where your DOMAIN and SR_FOLDER make up the IBFS location of your report (WFC/Repository/TENANT/SUB_FOLDER).

If you hit the link to the page directly and its still taking a long time, then you know its not the Portal overhead that is causing the issue. Remember you can only do this IF your user is already logged in to WF.

If you still are convinced that the issue is with the overhead of the Portal and you absolutely need to cut that time down, then I would probably open up a case with IBI. They will probably refer it to their service consulting team though. At this point, I think you are going to be talking about faster hardware, better internet speeds, more efficient network sort of solutions.

Hi Eric,

Perhaps it's not the time of downloading, but time of waiting. In chrome press F12 and open the network tab before loading the page. Then when loading check where views.bip is and check the timing. If it's waiting (TTFB) then it means it's just waiting on server response.

Yes you're correct, I didn't articulate this very well in my initial posting.

There could very well be things happening on the WF8 server that's causing the delay, not the downloading of the files themselves. And it just so happens that those (slow) events occur the same time that the 2 files get downloaded. So a better to ask my initial question would have been:

Has anyone seen similar behavior with WebFocus 8 , and what tuning did you do to improve performance?

We have speed issues that we have not fixed yet. But it was not has bad as trying to run the dashboards after the conversion from 7704. We rewrote all of Dashboards into Portals. We found going from ie8 to ie11 made it a lot faster also.

Thanks , its good to hear we're not the only company seeing these issues.

We never used 7, we started on WF8 so there's no legacy cobwebs to worry about. Also, this is customer facing so we don't have much control over what browser they use. That being said, we state in our Portal that we only support IE9 and higher. Still, we're seeing brutally slow behavior regardless of the browser -- chrome/firefox/IE/Safari, WF8 is crawling in all of them.

It's quite frankly just a matter of measuring. When you load a portal, multiple requests are fired at the client, from the client there are requests to the reporting server and the repository. Everything can have effect on the total performance. What kind of repository do you have, is it on the client server, wat kind of sql requests are fired with the reports? Are these requests fast?

Could you run the query for just views.bip isolated? When I do this for a big portal it takes 1,6 seconds.

Just use the developertools on chrome and firefox.