In our July WebSphere tip, "Monitoring WebSphere performance," you learned what resources WebSphere has, how WebSphere applications use those resources and how to monitor them. Now comes the challenging part: determining what to do when resources become low and cause a performance bottleneck. Resources become low when there is a high load on the system or when the available resources are poorly used by the applications that run on the system.
Collecting data for application tuning
If the user load -- the number of concurrent users attempting to access the system -- has not changed, then the likely cause of your problem is a new application using the resources poorly. Identifying the affected resources, the application using those resources, and the possible causes will prepare you for a diplomatic and constructive discussion with the application developer. After all, why tune the system to deal with poorly written applications?
To help you discuss the issue with the developer, it's a good idea to turn on the logging capability of the Tivoli Performance Viewer (formerly the WebSphere Resource Analyzer) to capture the data and provide evidence to help you and the developer determine the problem location. You can view data on resource performance by using the "View Chart" window, which displays a graph of time and performance value. To see a chart of a particular resource's performance:
- Select the resource in the "Resource Selection" pane.
- Click the "View Chart" tab within the "Data Monitoring" pain.
- To start recording the data, select "logging—On" and then use the "Save" box to give it a file name and format type (either a binary file or XML).
- To stop recording data, simply click "logging—off."
- When you want to replay the log, select "File—Open Log File," then indicate which file you want to replay.
Tuning resource settings
However, if you determine that an increase in user activity (users accessing the system concurrently) is the culprit, then tuning the resources (for example, increasing the size of the thread pool) is a good approach.
In this case, use the Administrators Console, which is a browser-based interface that provides configuration and operational capabilities. It is installed on the application server, with the administrator connecting to it via a browser client.
If you are sufficiently experienced with WebSphere administration, you can use Console to configure WebSphere resources manually. But you have to know what to change, and how. To change the thread pool size of your Object Request Broker, for instance, you would start the Console, highlight your application server, and click the "Services" tab in the property menu to edit properties of the ORB service. Then, simply type in maximum number of threads you wish to allow.
Alternatively, you can also use the Performance Tuning Wizard within the Console to configure resources automatically. If you are not familiar with WebSphere administration, it's best to start with the Performance Tuning Wizard and wait to do manual configuration until you've become familiar with the impact of making resource changes. To start the Performance Tuner, select it under the "Wizards" option on the main Console menu. If you wish to update the thread pool size, use a slider, which indicates the "normal" range of thread connections.
Choosing the right route to resolve performance issues
Now that you understand what resources WebSphere has, how those resources get used and how you can view and record the usage of those resources, you're empowered to make the right decision about performance issues. If the performance issues are related to increased user load or other system-related issues, consider tuning the environment and/or adding more machines to handle that extra load. After all, if more people are using the system, it has a higher value to the organization; therefore, it will be easier to justify adding hardware.
If the performance issue is due largely to an application, or perhaps multiple applications that are contending for the same resources, you can handle that in a number of ways. For example, if you see the number of sessions increasing, and never decreasing, you could ask the developer for a logout capability that releases the session. This can be easily added to an application (it's one line of Java code), or could be addressed by making the timeout value on sessions much shorter. But the key thing here is that you are empowered to make the right decision about how to address the performance issue.
Want to know more about performance monitoring and tuning? We highly recommend the IBM Redbook "WebSphere V5.0 Performance, Scalability and High Availability (SG24-6198-00)." As with all of IBM's Redbooks, it's extremely comprehensive and an excellent source of additional information.
About the authors:
Tony Higham is the chief solutions officer at FatWire Software and an expert on Lotus, WebSphere and Java technologies. He can be reached at tony.higham@FatWire.com.
Sue Hildreth is a contributing writer and editor based in Waltham, Mass. She can be reached at Sue.Hildreth@comcast.net.
Do you have comments on this tip? Let us know.
Please let others know how useful it is via the rating scale below. Do you have a useful Notes/Domino tip or code to share? Submit it to our monthly tip contest and you could win a prize and a spot in our Hall of Fame.
