In this section: |
PMF data mart and application are pre-tuned for optimal reporting and update performance, so further tuning of the application itself is not of concern for our customers. On the application side, every process entering and extracting data from the data mart has been already optimized to take advantage of enhancements possible in RDBMS database construction, SQL performance with WebFOCUS, and optimal use of resources from your environment.
In looking at performance you must look at the entire chain of connected processes that are involved when running PMF. The factors that can affect performance of the PMF application are listed below, from back-end to front-end:
Customers may notice suboptimal performance due to the demand placed by other applications on the machine. This can occur when a customer configures the PMF data mart in a busy application environment with other reporting applications and other transactional applications in the same RDBMS context.
To diagnose this issue, examine the configuration of your RDBMS server machine and determine if enough resources are allocated for the RDBMS to run at optimal speed. In some cases, an RDBMS server might be running on a multi-use machine that also runs other applications besides the RDBMS. Your RDBMS server might be sharing a machine with RDBMS or other application servers used by other parts of your organization.
Other things that should be considered are:
To test for optimization as you tune, perform queries of PMF data using SQL direct against the RDBMS server, using RDBMS tools. Also, perform queries of other data on the server. There are utilities included with PMF to simplify this testing for Oracle and they are located in C:\ibi\apps\pmfdbms\db_utils. Make sure to test this in isolation, outside of the WebFOCUS environment or PMF application.
The best practice for this configuration is a number of customers using PMF have a database exclusively configured for use with PMF, since this type of environment permits faster performance.
Customers that install PMF into a WebFOCUS configuration with other WebFOCUS high-demand reporting and multiple transactional applications might find that these other applications can place a stress on PMF that causes less than optimal performance. An example of this are PMF Dashboards, which use multiple server agents at run time.
Some best practices for this configuration are:
You could be experiencing slow performance with chart delivery in WebFOCUS if you have not allocated enough heap size and for your Java Application container.
Some best practices for this configuration are:
If your Web server has been configured in a multi-server load balanced environment, resulting in shared disk space between those multiple servers in order to enable all clients to receive web-server resident resources (such as pre-run charts or cached data), make sure the access to the shared network folder is as fast as possible, and that the shared folder is resident on the fastest-responding machine possible.
Slow network connections between your RDBMS server and your RDBMS Client (which feeds data over the adapter to the WebFOCUS Reporting Server), or slow network connections between your WebFOCUS Reporting Server and your WebFOCUS Client machine (which enables transmission of data to and from your Web server) can adversely affect performance. It is best to ensure that you keep the fastest network connection between these machines, as the connections make up the heart of your PMF and WebFOCUS environment.
In this section: |
PMF has the capability to run faster over slower Internet connections using:
PMF is a complex application with many dependencies on your RDBMS, WebFOCUS Server, WebFOCUS Client, Web Server, and browser. For optimal performance, and to operate PMF at full speed capacity, you need to tune your environment so it performs optimally. This is especially important if you are running the application on the Internet or in the cloud.
It is not possible for any application to speed up your network, optimize the standard Web servers of your company, or increase the processing capacity of your provisioned server hardware.
Application performance is never automatic. It must be designed into the application and then enforced in the environment. Depending on the performance and response time expected, optimizing application performance might require you to review every possible choke point.
The first thing that must be determined is what is the expected performance of the application in seconds. Once you know the expected speed, you should review the entire setup of the environment in order to explore all of the possible performance choke points.
The following performance settings should be reviewed:
Note: PMF asks the RDBMS to perform the summarization of your metrics due to the fact that transferring many millions of rows of metric data over to WebFOCUS for summarization would cause very slow performance. The SQL issued from PMF is optimized to request summaries from the RDBMS on the dimensional intersections used for the metrics.
You can check the timings for your RDBMS query by running a PMF report, or looking at the View Source in your browser, and reviewing the traces as shown below the final </html> tag.
To help determine if the RDBMS should be optimized, look for the following line:
-* ++++++++++++++++++++++++++++++++++++++++ Run time for Step(s) Extract Normal Measure Data: nn.nnn seconds
If nn.nnn is more than 3 seconds, the RDBMS should be optimized.
Note that if you set Application Tracing to ON in the PMF Settings section that can be found in the Manage tab, you will see a very detailed tree.
The following is a set of guidelines to maximize the response capability of your WebFOCUS environment in order to allow optimum performance of any real-time applications, including PMF.
For prestarted agents, use the following calculation:
total users * total estimated concurrency factor * total expected simultaneous demand * 8
This determines the number of pre-started agents that you will need to support PMF concurrency with limited latency,
To calculate the real memory needed for agents, assume that an average memory footprint is 7MB/agent. The calculation would be pre-started agent count x 7BM. For example, if the max total users is 300, the concurrency factor is 50%, and the demand factor is 10%, you get (300 * 0.5 * 0.1) or 7.5. Multiply this by 8 agents and get 60. 60 * 7MB = 420MB of memory to support agents.
If you need to disable minification for any reason, you can find the setting to enable or disable minification by going to the Manage tab, selecting Settings and then System. Setting Run Minimized to OFF will disable minification. The default is on and should be left ON for the best web performance.
If you system is not optimized for performance, your PMF Dashboards or other operational parts of the application might run more slowly than expected. If this situation occurs, you may see a semaphore timeout message from PMF, which indicates that AJAX processes have taken longer than expected.
You can extend the amount of time PMF waits for AJAX processes to complete by changing the AJAX Timeout setting. In the Manage tab, select Settings and then System. Set the number of seconds PMF should wait for AJAX processes to complete and return in the Ajax Timeout field. 30 seconds is the default.
The browser version you use can cause slow down performance and speed tests conducted on more recent browsers show performance increase. For example, JavaScript and HTML rendering speed differences between MS Internet Explorer 6 and MS Internet Explorer 8 reveal a speed increase by a factor of 10.
Another aspect to take into consideration is browser configuration. If PMF is loading very slowly after a fast display of the portal, make sure the website from which you are accessing PMF has been configured in Internet Explorer as an intranet site. The security status of the current site can typically be seen on the Internet Explorer status bar.
If the Internet Explorer status bar says the PMF Website is Internet, then the PMF JavaScript components are being examined by Internet Explorer every time you access the site, which considerably slows down PMF runtime.
If you certify the site in your browser as Local Intranet, you will skip the extra examination steps and PMF will run considerably faster. Since the PMF server is already an intranet site by definition, this action simply confirms this.
As of MS Internet Explorer 8, and with all previous versions, you certify this by clicking Tools, selecting Internet Options, and then clicking the Security tab. Then, click Local Intranet Site or Trusted Site, click Sites and then Advanced. Make sure the Web server root of your site is listed there. If it is not, add it.
If the procedure above does not match your version of Internet Explorer, consult the Internet Explorer Help for more information.
Note: If you have a lot of PMF users at your site, you can configure a Site Policy to mass-configure this for all your users. For more information on how to set up a Site Policy, please consult your Microsoft Windows administration documentation.
If the PC running the browser has a lot of resident applications and not enough memory to run them, browser performance can be adversely affected. Make sure your machine is configured with enough real memory to enable fast performance.
Also, ensure that any anti-virus software is not checking needed browser application components at run time. Certain anti-virus applications can be configured to examine JavaScript resources and other components indiscriminately.
WebFOCUS |