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:
Testing under realistic load may uncover bugs not seen during development or QA.
Testing your prototype under load will help you validate design decisions early in the development cycle that may significantly alter the performance of your application.
Any configuration change can dramatically affect application performance (hardware, database, clustering environment, application tuning parameters, and so on). Load testing your application whenever design changes are made provides a way to narrow down performance problems to a particular area.
Testing early and often increases the likelihood that your site implementation and deployment will perform well.
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.
First, perform the following steps to identify performance issues with your network, database, or other software that is independent of WebLogic Portal.
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.
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.
Test your web server, ensuring that it has sufficient capacity to serve static HTML pages when many concurrent threads are running.
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.
After performing the steps in the previous section, General Architecture, perform the following steps to identify performance issues with WebLogic Portal:
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.
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.
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.
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.
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.
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, theWebLogic 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.