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

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,

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?

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.

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.

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.

Tech Support says the same thing when Composer eats my HTML. So I'm in the same boat either way

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!

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?

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.