Focal Point
Improving Response Times

This topic can be found at:
http://forums.informationbuilders.com/eve/forums/a/tpc/f/7971057331/m/1887092336

September 06, 2013, 05:25 PM
eric.woerle
Improving Response Times
I am looking at the performance of some of my pages. The particular page in question takes 15 seconds to load. Looking at the network information through chrome i've found it to break down as such:

-5 seconds in miscellanous wfservlet calls. Then
- 6 seconds in loading the dynamic checkboxes(these are loading serially at about 1.2 seconds per checkbox group for 5 groups)
-4 seconds report run time

To me, the report taking about 4 seconds is good for the communication and return of the records needed. I wish I new what wfservlet calls WF was issuing to prepare the page, but I don't know if I'll be able to speed those up anyways. Where I see some room for improvement is in the loading of the dynamic checkboxes. These are not chainned together (They are chained to a single static value, but not to each other). Does anyone know how I would get the remote values to run in parallel as opposed to serial? Also any other performance tuning tips would be appreciated.


Eric Woerle
8.1.05M Gen 913- Reporting Server Unix
8.1.05 Client Unix
Oracle 11.2.0.2
September 08, 2013, 05:20 AM
FrankDutch
Eric

It seems you created a screen where users
S are supposed to create different reports.
I also found out that this loading takes a bit overhead and tried to explain to the users that they better should keep the selection page opened .
But the do not...after running the report most of them close the whole dashboard.
10 min later...an other report is needed and they start the dashboard again.
I think...the 10sec you might win is not important enough for most users.
According to the checkboxes..do you have little queries behind it to show drop down lists? Maybe these can be more efficient .




Frank

prod: WF 7.6.10 platform Windows,
databases: msSQL2000, msSQL2005, RMS, Oracle, Sybase,IE7
test: WF 7.6.10 on the same platform and databases,IE7

September 09, 2013, 01:12 PM
eric.woerle
Frank,

Thanks for your thoughts.

This report is one report that is called through an IFrame from another tool. So the user is meant to move to and from this page. Like I mentioned earlier, I don't think there is something I can do about the initial overhead from WebFOCUS, I think the user is just going to have to live with it. Where I was hoping to be able to save some time is in the loading of the Dynamic Checkboxes. At 1.2 seconds to run each series of checkboxes, I don't see that as taking up to much time. It is that they are being run serial instead of parallel. If I can get them all to run at the same time, then I might be able to bring it down from 6 seconds to 2 or 3. I think that should be a sufficient win for me. Any thoughts on how to make the dynamic values run in parallel as opposed to serial?


Eric Woerle
8.1.05M Gen 913- Reporting Server Unix
8.1.05 Client Unix
Oracle 11.2.0.2
September 09, 2013, 01:37 PM
j.gross
Serial (synch) or parallel (asynch) processing of the requests to populate controls depends on the javascript that WF generates; as it stands I think you are stuck with synch.

Suggestions:

1. How much of the 1.2 sec is spent on actual data retrieval (as opposed to call-setup overhead)? If it's significant (say, sifting through numerous account records to list all distinct values of whatsis), you can save execution time by pre-computing and storing the answer lists for each possible parameter value (the "single static value").

2. Since the parameter that determines the size and content of the groups is known to WF when it generates the page ("They are chained to a single static value"), in principle you can populate the groups within WF, before the page is sent to the browser (HOLD FORMAT HTMTABLE & -HTMLFORM), thus avoiding the five browser-to-WFRS calls altogether.
September 09, 2013, 04:25 PM
eric.woerle
j.gross,

I don't think I can bring the response time for each individual check box down from 1.2 seconds since the fact table has less then 1000 records in it. Most, if not all of that has to be WF / Oracle overhead. But to your second point, could you expand on that a bit?

To clarify what I was talking about with the static value I pass. I have some 20 or so fexes to populate drop down boxes shared by 15 reports. The purpose of the static value is to pass an indicator to the drop downs, that depending on which value I send, I filter those drop downs in slightly different ways. Using this Filter Indicator, I was able to save myself from having to create 60 more fexes for drop downs. A HUGE savings in my eyes for one variable.

but on to your concept. I don't think this is exactly what you meant, but its along those lines. In theory, I could write a flat file to FOCACHE in preprocessing. These flat files would be the check box values that are now handled dynamically, and then I could use !IBI_FIL to bring them onto the html page.

Is that kind of where you were going? Although I bet what you meant would be a more elegant solution.


Eric Woerle
8.1.05M Gen 913- Reporting Server Unix
8.1.05 Client Unix
Oracle 11.2.0.2
September 09, 2013, 04:46 PM
j.gross
Yes. The point is to generate the dropdown code before the page hits the browser.

There was a time (ver 4.something) when you could use -htmlform multiple times in a fex, to build the html page a step at a time. I guess that memory fogged my mind. !IBI.FILE.xxx;, as you outlined, is correct.

That said, if you construct the page in Composer and it misbehaves after you manually introduce those !IBI's, tech support will likely say you're on your own.
September 09, 2013, 05:00 PM
eric.woerle
Tech Support says the same thing when Composer eats my HTML. So I'm in the same boat either way Smiler

Short side rant, It amazes me how Composer treates "position: relative" with extreme prejudice and always converts it to "position: absolute". If I wanted absolute positioning, I WOULD SAY ABSOLUTE POSTIONING. OK Side rant over...

I'll try using 5 text files in FOCACHE and see how that works.

Thanks for the help!


Eric Woerle
8.1.05M Gen 913- Reporting Server Unix
8.1.05 Client Unix
Oracle 11.2.0.2
September 20, 2013, 11:20 AM
eric.woerle
Just had a thought. In looking at the network calls, I noticed some 14 wfservlet calls in a row using IBIRLS3. Then the thought came to me. The Composer leaves a bunch of old Request ID XML tags in the code that are no longer used. Does anyone know if WebFOCUS needs to run each of those request ids when launching a page? If I were to clean those up, should I expect to see less then the 14 serial WFServlet calls?


Eric Woerle
8.1.05M Gen 913- Reporting Server Unix
8.1.05 Client Unix
Oracle 11.2.0.2
September 20, 2013, 11:32 AM
Steve
Something else to look at:

We had found that turning off auto-prompting on MRE reports could have a significant impact (especially if the fex files are large and contain a large number of amper variables). In some instances, it cut 50% off of the total time to render a report.


WebFOCUS 7.7.02 Teradata, Oracle
Windows
Outputs: HTML / PDF / Excel