Tune parameter hot list
The following hot list contains recommendations that have improved performance or scalability, or both, for many applications.
WebSphere Application Server provides several tunable parameters and options to match the application server environment to the requirements of the application.
- Review the hardware and software requirements
It is critical for proper functionality and performance to satisfy the minimum hardware and software requirements. Refer to IBM WebSphere Application Server supported hardware, software, and APIs website which details hardware and software requirements.
- Install the most current refresh pack, fix pack, and the recommended interim fixes
The list of recommended updates is maintained on the Support site.
- Check hardware configuration and settings
Check network connections to verify they are running at their highest speed. For more information, see Tune the application serving environment.
Verify network interconnections and hardware configuration is setup for peak performance.
- Tune the operating systems
Operating system configuration plays a key role in performance. For example, adjustments such as TCP/IP parameters might be necessary for your application
- Tune IBM i systems
Operating system configuration plays a key role in performance. For example, adjustments such as TCP/IP parameters might be necessary for the application.
- IBM Power Systems Performance Capabilities Reference IBM i operating system Version 7.2
- Web Performance Advisor
- Set the minimum
and maximum JVM heap sizes
Many applications need a larger heap size then the default for best performance. It is also advised to select an appropriate GC policy based on the application's characteristics.
- Use a type 4 (or pure Java)
JDBC driver
In general, the type 2 JDBC driver is recommended if the database exists on the same physical machine as the WebSphere instance. However, in the case where the database is in a different tier, the type 4 JDBC driver offers the fastest performance since they are pure Java not requiring native implementation. Use the previous link to view a list of database vendor-specific requirements, which can tell you if a type 4 JDBC driver is supported for the database.
- Use a type 2 JDBC driver for local data access and a type 4 (or pure Java) JDBC driver for remote data
access
In general, the type 2 JDBC driver is recommended. Use the previous link to view a list of database vendor-specific requirements, which can tell you if a type 4 JDBC driver is supported for the database.
- Tune WebSphere Application Server JDBC data sources
and associated connection pools
The JDBC data source configuration might have a significant performance impact. For example, the connection pool size and prepared statement cache need to be sized based on the number of concurrent requests being processed and the design of the application.
See the Connection pooling topic for more information.
- Enable
the pass by reference option
Use applications that can take advantage of the pass by reference option to avoid the cost of copying parameters to the stack.
- Ensure that the transaction log is assigned to a fast disk
Some applications generate a high rate of writes to the transaction log. Locating the transaction log on a fast disk or disk array can improve response time.
- Tune related components, for example, database
In many cases, some other component, for example, a database, needs adjustments to achieve higher throughput for the entire configuration.
- Disable functions that are not required
For example, if your application does not use the web services addressing (WS-Addressing) support, disabling this function can improve performance.
Use this property with care because applications might require WS-Addressing MAPs to function correctly. Setting this property also disables WebSphere Application Server support for the following specifications, which depend on the WS-Addressing support: Web Services Atomic Transactions, Web Services Business Agreement and Web Services Notification.
To disable the support for WS-Addressing, refer to Enable Web Services Addressing support for JAX-RPC applications
- Tune index
One of the goals of the product programming model and runtime is to significantly simplify the work required for application developers to write and deploy applications. Sometimes we say that the product relieves the application programmer of many of the plumbing tasks involved in developing applications. For example, application code in the product does not concern itself directly with remote communication--it locates objects which may be local or remote and drives methods. Therefore, you won't see any direct use of socket calls or TCP/IP programming in this application code.
This separation of what to do from where you do it is one aspect of removing the application programmers from plumbing tasks. Other considerations are not having to deal with data calls for some types of beans, potentially user authentication, and threading. There are generally no calls from the application code to touch sockets, RACF calls, or management of threading. Removing this from the application programmer doesn't mean this work won't get done. Rather, it means that there may be more work for the DBA, the network administrator, the security administrator, and the performance analyst.
There are four layers of tuning that need to be addressed:
- Tune the z/OS operating system
- Tune the subsystems
- Tune the product runtime
- Tune for J2EE applications
We deal with the first three in separate sections under this article and briefly touch on the fourth. For more information on tuning applications, refer to Use application clients.
- Tune the z/OS operating system
- Tuning
the subsystems
Steps involved in tuning the z/OS subsystems to optimize product performance include:
- DB2 tuning tips for z/OS
- Security tuning tips
- Tune TCP/IP buffer sizes
- Tune GRS when using global transactions in z/OS
- Tune the IBM virtual machine for Java
- Tune for applications that access CICS in z/OS
- DB2 tuning tips for z/OS
- Tune the product runtime
Steps involved in tuning the product runtime to optimize performance include reviewing the:
- Review the product configuration
- Internal tracing tips for the product
- Location of executable programs tips for z/OS
- Security tuning tips
- Review the product configuration
- Review the product configuration
The first thing to do is review the product configuration. One simple way to do this is to look in the application control and server regions in SDSF. When each server starts, the runtime prints out the current configuration data in the job log.
- Internal tracing tips for the product
Product traces can be extremely helpful in detecting and diagnosing problems. By properly setting trace options, we can capture the information needed to detect problems without significant performance overhead.
- Verify that you are not collecting more diagnostic data than we need.
You should check the tracing options to verify that the ras_trace_defaultTracingLevel property is set to 0 or 1, and that the ras_trace_basic, and ras_trace_detail properties are not set.
How to view or set: In the administrative console:
- Click Environment > WebSphere variables.
- On the Configuration Tab check for any of these properties in the name field and observe their settings in the value field.
- To change the setting for one of these properties, click the property name the name field, and then specify the new setting in the value field. We can also describe the setting in the description field on this tab.
- To add one of these properties, click New, and then specify the property name the name field, and the property setting in the value field.
- Click Environment > WebSphere variables.
- If we use any level of tracing, including ras_trace_defaultTracingLevel=1, verify that the ras_trace_outputLocation property is set to BUFFER.
When the ras_trace_defaultTracingLevel property is set to 1 exceptions are written to the trace log as well as to the ERROR log.
- It is best to trace to CTRACE.
If we are tracing to SYSPRINT with ras_trace_defaultTracingLeve set to 3, you might experience an almost 100% throughput degradation. If we are tracing to CTRACE, however, you might only experience a 15% degradation in throughput.
- It is best to trace to CTRACE.
- Set the ras_trace_BufferCount property to 4 and the ras_trace_BufferSize property to 128.
This setting reserves 512 KB of storage for the trace buffers, which is the minimum amount of storage allowed, and reduces memory requirements.
- Disable JRAS tracing.
To disable JRAS tracing, look for the following lines in the trace.dat file that is pointed to by the JVM properties file:
com.ibm.ejs.*=all=disable com.ibm.ws390.orb=all=disable
Verify that both lines are set to disable, or delete the two lines.If a value is specified for the ras_trace_outputLocation property, you might be tracing and not know it.
- Verify that you are not collecting more diagnostic data than we need.
- Location of executable programs tips
The next thing to review in the configuration is where your program code is located. IBM recommends that you install as much of the product code in LPA as is reasonable. This ensures that we have eliminated any unnecessary steplibs which can adversely affect performance. If use STEPLIBs, verify that any STEPLIB DD in the controller and servant procs do not point to any unnecessary libraries. Refer to UNIX System Services (USS) tuning tips for z/OS for USS shared file system tuning considerations.
If you choose to not put most of the runtime in LPA, you might find that your processor storage gets a bigger workout as the load increases. At a minimum, the product starts three address spaces, so that any code that is not shared loads three copies rather than one. As the load increases, many more servants might start and contribute additional load on processor storage.
Review the PATH statement to ensure that only required programs are in the PATH and that the order of the PATH places frequently-referenced programs in the front.
- Tuning
for J2EE applications
Steps involved in tuning the J2EE applications performance include:
-
- Tune TCP/IP buffer sizes
- Tune for SOAP
- Tune message-driven bean processing on z/OS by using WebSphere MQ as the messaging provider in ASF mode
-
- Review the application design
We can track many performance problems back to the application design. Review the design to determine if it causes performance problems.
Related tasks
Related information:
IBM Systems Workload Estimator
Reference topic