Performance Tuning Guide

     Previous  Next    Open TOC in new window    View as PDF - New Window  Get Adobe Reader - New Window
Content starts here

General Performance Tuning Guidelines

WebLogic Portal application performance is affected by many factors. This chapter discusses a few of the initial aspects that can affect performance and provides links to documentation resources that can assist you.


Understanding Performance Tuning and Oracle WebLogic Portal

Performance tuning is a process which spans development, staging and deployment. During all phases, performance should be monitored and appropriate adjustments made. If you are new to performance testing, see Approaches to Performance Testing on the Oracle Technology Network web site.

Oracle recommends that you establish an environment where you can performance test the installation for the following reasons:

The recommended approach for performance testing is to start with the simplest aspect of the installation and then move into areas of increased complexity. If you observe slow behavior in any portion of this testing process, you should begin a more thorough investigation into its causes.

General Architecture

First, perform the following steps to identify performance issues with your network, database, or other software that is independent of WebLogic Portal.

  1. Test your database (independent of any web components) to determine how well your schema and SQL work. Note any areas where the schema or SQL may not be optimized for performance. See the WebLogic Portal Database Administration Guide for more information about proper setup and performance tuning.
  2. Test your network for sufficient bandwidth, and check that the TCP/IP parameters on the server’s operating system can sufficiently handle the application load you expect. It is possible that the network is the slowest aspect of your deployment. Ensure that your IP Multicast for cluster deployment is configured correctly. See the WebLogic Server Troubleshooting Multicast Configuration Guide for more information about multicast configuration.
  3. Test your web server, ensuring that it has sufficient capacity to serve static HTML pages when many concurrent threads are running.
  4. Ensure that you have enough resources available to meet application requirements. Most large applications are clustered, but keep in mind that a clustered environment requires resources to perform load-balancing tasks. For more information, see Understanding Cluster Configuration and Application Deployment.
  5. Test your servlet engine by running a load test against a trivial servlet such as a HelloWorld servlet. If this simple servlet does not perform and scale horizontally (meaning that as you add Java Virtual Machines, performance increases accordingly), the performance problems you encounter may be related to an infrastructure or resource issue.

WebLogic Portal

After performing the steps in the previous section, General Architecture, perform the following steps to identify performance issues with WebLogic Portal:

  1. Verify that your Oracle WebLogic Portal database configuration is optimal. WebLogic Portal makes extensive use of the database. Check that your connection pool is large enough and verify that your database handles connection failures in an efficient manner. For example, the size of the JDBC connection pool should be set to handle the maximum number of concurrent users as possible, and it should be set on server startup rather than growing as connections are needed. This will increase the server startup time but will decrease the overhead creating those connections under server load. See the section “Performance Considerations” in the WebLogic Portal Database Administration Guide for more information.
  2. Verify that each portlet is optimized for speed as follows:
    • If a portlet uses forms that update the data within the portlet this will cause the entire portal to refresh its data, which can be very time consuming. Therefore, portlets that have this behavior should have asynchronous rendering enabled via AJAX or iFrames so that the overall rendering of the portal is not affected. AJAX is supported at the portal desktop and individual portlet levels.
    • Note: Individual portlets with asynchronous rendering methods have limitations such as not supporting inter portlet communication.
    • Place items that require heavy processing in an edit page or a maximized URL. If you do not, the portal must wait for the portlet to process, and this considerably slows down the eventual rendering of the portal. Process intensive portlets may benefit from parallel portlet rendering (also known as pre-render and render forking.) For more information about this see “Optimizing Portlet Performance” in the Portlet Development Guide.
    • Enable caching on portlets that do not rely on dynamic data.
  3. Test your application’s components, starting from the data access layer. Then proceed toward the GUI one step at a time. Pay attention to performance and scalability differences at each component and between each layer of your application. Finally, do end-to-end testing from a browser-based load-testing tool.
  4. Test the behavior and performance of your application under simulated, real-world conditions. (Many tools are available to help you do this.) Be sure to use both anonymous and logged-in users simultaneously.


Tuning Your WebLogic Server

Because WebLogic Portal runs on WebLogic Server, factors impacting the performance of WebLogic Server will also impact the performance of WebLogic Portal.

For more information about tuning WebLogic Server, see the WebLogic Server Performance and Tuning Guide.

Table 1-1 lists the top ten tuning recommendations for WebLogic Server.

Table 1-1 Top Ten Tuning Recommendations
Tuning Question
For Information, See:
How big should the JDBC connection pool be?
How to use JDBC caches?
What optimizations are there for transactional database applications?
How many connections should WebLogic Server accept?
What is the optimal size of the WebLogic Server network layer?
What type of Entity Bean cache should be used?
How to avoid serialization when one EJB calls another?
How to load related beans using a single SQL statement?
How to tune session persistence?
What is the optimal JMS configuration?


Tuning Your JVM

Your Java Virtual Machine is key to running your Portal efficiently. For more information about tuning WebLogic JRockit, see the Diagnostics Guide in the JRockit documentation.


When using JRockit, there are many different flags available. Depending on the application and the SLA, different parameters and garbage collection flags should be used. It is strongly recommended that before changing any parameters the application should be baselined so that the performance differences between subsequent tests can be measured. When using Sun Hotspot, adjust the -XX:MaxPermSize to be a minimum of 128MB.


Tuning Your Database

Keeping your database tuned is an important part of using WebLogic Portal. Portal uses the database to store content, rules, portal framework objects (streaming desktops, books, pages, and portlets), customizations, and user profile data.

Best practices for production deployment will vary between database vendors. See the database vendor documentation for these best practices. For WebLogic Portal specific tuning recommendations see, the WebLogic Portal Database Administration Guide.


Tuning Your Operating System

Tune your operating system according to your operating system documentation. Oracle certifies WebLogic Platform on multiple operating systems, see the WebLogic Platform Supported Configurations page for more details.

Following the WebLogic Server Performance and Tuning Guide is strongly recommended.


Other Resources

Remember that WebLogic Portal uses many components from WebLogic Server. See the following documentation for more information:

  Back to Top       Previous  Next