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     [CLOSED] Dashboard Performance

Read-Only Read-Only Topic
Go
Search
Notify
Tools
[CLOSED] Dashboard Performance
 Login/Join
 
MattC
Guru
posted
Hi all. Right now we are in the process of building a pretty extensive real time dashboard with several reports. They way we have this currently setup is that we have a dashboard with 3 tabs and on each tab we have a launch fex that launches HTML with frames and in each frame there is a report fex.

Well the bottom line is we are looking at the performance aspect of this. As a user launches the dashboard, immediately the user lands on a tab that executes at least 6 agents on the reporting server. As a user navigates throughout the dashboard among the tabs or drills or changes dates, the user can have multiple concurrent agents running which absorbs CPU. We have conducted several load tests and as we bring in more users, we are noticing some pretty large response times as we notice that the CPU on the reporting server is pegged at a 100%. Database response is quick and our results indicate there is not an issue on the database side. The report fex’s are all using SQL pass thru with pretty much a single pull.

An expectation has been set that no matter what a user does their average response time for all the reports in the dashboard should come back in about 15 seconds. Well as we increase the concurrent users, the response time surpasses the 15 second expectation.

Right now we have a single Solaris WF Client to a Single Windows Reporting Server. (2 CPU, 4gb of ram) We are looking at our options to scale the Reporting Server.

At the end of this project for this dashboard, we should end up with over 1,000 users where during peak hours of the day at around 15% to 20% of the 1,000. We also have other projects for other dashboards with similar requirements.

What I am looking for is if anyone else has been in this situation, what type of environment did you have and how was it scaled? What type of Reporting Server setting changes would you recommend? How did you handle the one user to multiple agents?

Any suggestions would be grateful.

Thanks

This message has been edited. Last edited by: Kerry,


WebFOCUS 8.1.05
 
Posts: 496 | Registered: January 04, 2008Report This Post
Doug
Expert
posted Hide Post
Are you sure that you're barking up the right tree here? What do your reports look like in each of those tabs (as far as run times)? How efficient are they? I'm thinking along the lines of increasing the efficiency of the code within those reports. Our users want the reports to run in less then FIVE seconds. We're having a difficult time with that and are looking in to the report efficiencies as well as server / network alternatives. For analysis, run the dashboard with very minimal fexes and see check the timing there as well as running the reports to check their run times. Be sure to take in to account the loading of any controls in your launch pages…

I hope this helps a bit,
Doug




   In FOCUS Since 1983 ~ from FOCUS to WebFOCUS.
   Current: WebFOCUS Administrator at FIS Worldpay | 8204, 8206
 
Posts: 3132 | Location: Tennessee, Nashville area | Registered: February 23, 2005Report This Post
dhagen
Virtuoso
posted Hide Post
You should ask this question of CSS. There are lots of things that you can do to aid with performance. A few are:
- Pre-compile JSPs at application server
- JVM settings for both application server and JSS
- Cache settings for WFRS and application server
- Prebuilt XMLs for drop downs
- WFRS pooled connections
- DBMS adapter settings to enhance performance
- Multiple WFRS on same platform
- Queues in WFRS to control concurrent user requests

Those are off the top of my head. I'm sure that the people in CSS can expand that list. There is a group there that live and die performance. Tap into them.


"There is no limit to what you can achieve ... if you don’t care who gets the credit." Roger Abbott
 
Posts: 1102 | Location: Toronto, Ontario | Registered: May 26, 2004Report This Post
Francis Mariani
Expert
posted Hide Post
quote:
Those are off the top of my head

D, that must be a very big head Big Grin


Francis


Give me code, or give me retirement. In FOCUS since 1991

Production: WF 7.7.05M, Dev Studio, BID, MRE, WebSphere, DB2 / Test: WF 8.1.05M, App Studio, BI Portal, Report Caster, jQuery, HighCharts, Apache Tomcat, MS SQL Server
 
Posts: 10577 | Location: Toronto, Ontario, Canada | Registered: April 27, 2005Report This Post
MattC
Guru
posted Hide Post
Thanks for the responses. As far as the reports, they are pretty efficient. We have reviewed these procedures over and over and we have pretty much tuned them inside and out. Response time for a single user is roughly 5 seconds for the dashboard to load. What I did learn from IBI is that there is an agent to CPU ratio and that is roughly 20-40 agents per CPU (concurrent). If this being the case, I am curious what other customers are doing out there with their dashboards.

From what I read, Queuing is not really an option, but I am curios about that WFRS pooled connections? What are you referring to here? I know that you can add more reporting servers, but I kind of wanted to get a real feed back on how other companies are using similar type dashboards and what does their environment look like and how response is it.


WebFOCUS 8.1.05
 
Posts: 496 | Registered: January 04, 2008Report This Post
dhagen
Virtuoso
posted Hide Post
quote:
I kind of wanted to get a real feed back ...
I did give you real feedback! That was a small list (all or some combination) of things that I would do for my customers to get max performance.

From the server console help screens:
quote:

deployment = private or connection_pooling

Internal default: private

This keyword controls resource sharing between users who are connecting to the same agent in this service. See Workspace Manager Configuration for a detailed description.

In private deployment all users are completely independent of each other and have their unique OS rights , DBMS connections and FOCUS language settings.
· All profiles are executed on each connection.
· The FOCUS context (i.e. DEFINEs, JOINs, global &&variables, USEs, file allocations - FILEDEFs, DYNAMs, etc. and all FOCUS settings) is cleared on each connection
· With security mode OPSYS, effective user ID is switched to the connecting user for the duration of the connection.
· All DBMS connections are dropped and reestablished with each connecting user..
· Each user or group can have his own application path

In connection_pooling deployment all users are partially independent of each other by having their own unique FOCUS language settings but sharing OS rights and DBMS connections.

· Global profile and service profile are executed when agent is started and pooled user profile is executed on each connection.
· The FOCUS context (i.e. DEFINEs, JOINs, global &&variables, USEs, file allocations - FILEDEFs, DYNAMs, etc. and all FOCUS settings) is cleared once session is established for a new connection.
· All users have the same OS rights because the effective user is unique (pooled_user) regardless of the connecting user.
· All DBMS connections are established at server startup and are reused saving the connect/disconnect cost.
· The DBMS connections are defined in the Global profile according to the standard adapter connection rules.
1. For explicit connection the explicitly defined user id used.
2. For a trusted connection with security mode OPSYS the pooled_user becomes the effective DBMS user.
3. Passthru option should not be used, since the connecting user is not known at the server startup.
· All users share server controlled application path as defined in the Global profile unless overridden by the client.

Connection_pooling provides a significant performance advantages and should be used when large number of users share the same OS and DBMS credentials. It cannot be used when each connecting user has specific OS and DBMS rights. It cannot be used for the service DEFAULT with the server configured with security mode DBMS as it disable per connection authentication.


"There is no limit to what you can achieve ... if you don’t care who gets the credit." Roger Abbott
 
Posts: 1102 | Location: Toronto, Ontario | Registered: May 26, 2004Report 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     [CLOSED] Dashboard Performance

Copyright © 1996-2020 Information Builders