Focal Point Banner


As of December 1, 2020, Focal Point is retired and repurposed as a reference repository. We value the wealth of knowledge that's been shared here over the years. You'll continue to have access to this treasure trove of knowledge, for search purposes only.

Join the TIBCO Community
TIBCO Community is a collaborative space for users to share knowledge and support one another in making the best use of TIBCO products and services. There are several TIBCO WebFOCUS resources in the community.

  • From the Home page, select Predict: WebFOCUS to view articles, questions, and trending articles.
  • Select Products from the top navigation bar, scroll, and then select the TIBCO WebFOCUS product page to view product overview, articles, and discussions.
  • Request access to the private WebFOCUS User Group (login required) to network with fellow members.

Former myibi community members should have received an email on 8/3/22 to activate their user accounts to join the community. Check your Spam folder for the email. Please get in touch with us at community@tibco.com for further assistance. Reference the community FAQ to learn more about the community.


Focal Point    Focal Point Forums  Hop To Forum Categories  WebFOCUS/FOCUS Forum on Focal Point     Improving Response Times

Read-Only Read-Only Topic
Go
Search
Notify
Tools
Improving Response Times
 Login/Join
 
Master
posted
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
 
Posts: 750 | Location: Warrenville, IL | Registered: January 08, 2013Report This Post
Virtuoso
posted Hide Post
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

 
Posts: 2387 | Location: Amsterdam, the Netherlands | Registered: December 03, 2006Report This Post
Master
posted Hide Post
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
 
Posts: 750 | Location: Warrenville, IL | Registered: January 08, 2013Report This Post
Virtuoso
posted Hide Post
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.
 
Posts: 1925 | Location: NYC | In FOCUS since 1983 | Registered: January 11, 2005Report This Post
Master
posted Hide Post
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
 
Posts: 750 | Location: Warrenville, IL | Registered: January 08, 2013Report This Post
Virtuoso
posted Hide Post
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.
 
Posts: 1925 | Location: NYC | In FOCUS since 1983 | Registered: January 11, 2005Report This Post
Master
posted Hide Post
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
 
Posts: 750 | Location: Warrenville, IL | Registered: January 08, 2013Report This Post
Master
posted Hide Post
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
 
Posts: 750 | Location: Warrenville, IL | Registered: January 08, 2013Report This Post
Member
posted Hide Post
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
 
Posts: 13 | Location: Michigan | Registered: December 09, 2008Report This Post
  Powered by Social Strata  

Read-Only Read-Only Topic

Focal Point    Focal Point Forums  Hop To Forum Categories  WebFOCUS/FOCUS Forum on Focal Point     Improving Response Times

Copyright © 1996-2020 Information Builders