WAS traditional Recipes

1. Review the Operating System recipe for your OS. The highlights are to ensure CPU, RAM, network, and disk are not consistently saturated.
2. Review the Java recipe for your JVM. The highlights are to tune the maximum heap size (-Xmx or -XX:MaxRAMPercentage), the maximum nursery size (-Xmn) and enable verbose garbage collection and review its output with the GCMV tool.
3. Ensure that the application thread pools are not consistently saturated: HTTP = WebContainer, EJB = ORB.thread.pool, JMS activation specifications over MQ = WMQJCAResourceAdapter, JMS over SIBus = SIBJMSRAThreadPool, z/OS = ORB workload profile setting, etc.
4. Consider reducing the default Hung Thread Detection threshold and interval which will print a warning and stack trace when requests exceed a time threshold.
5. If receiving HTTP(S) requests:
   1. For HTTP/1.0 and HTTP/1.1, avoid client keepalive socket churn by setting Unlimited persistent requests per connection.
   2. For servers with incoming LAN HTTP traffic from clients using persistent TCP connection pools with keep alive (e.g. a reverse proxy like IHS/httpd or web service client), consider increasing the Persistent timeout to reduce keepalive socket churn.
   3. For HTTP/1.0 and HTTP/1.1, minimize the number of application responses with HTTP codes 400, 402-417, or 500-505 to reduce keepalive socket churn.
   4. If using HTTP session database persistence, tune the write frequency.
   5. For increased resiliency, if using HTTPS, set -DtimeoutValueInSSLClosingHandshake=1.
   6. If possible, configure and use servlet caching/Dynacache for HTTP response caching.
   7. Consider enabling the HTTP NCSA access log with response times for post-mortem traffic analysis.
   8. If the applications don't use resources in META-INF/resources directories of embedded JAR files, then set com.ibm.ws.webcontainer.SkipMetaInfResourcesProcessing = true.
   9. Consider reducing each TCP Transport's Maximum open connections to approximately the expected maximum number of concurrent processing and queued requests that avoids excessive request queuing under stress, and test with a saturation & slow performance test.
6. If using databases (JDBC):
   1. Connection pools should not be consistently saturated. Tune each pool's Maximum connections.
   2. Consider tuning each data source's statement cache size and isolation level.
   3. Consider disabling idle and age connection timeouts by setting reap time to 0 (and tune any firewalls, TCP keep-alive, and/or database connection timeouts, if needed).
   4. Compare relative results of globalConnectionTypeOverride=unshared.
7. If using JMS MDBs without a message ordering requirement, tune activation specifications' maximum concurrency to control the maximum concurrent MDB invocations and maximum batch size to control message batch delivery size.
8. If using authentication:
   1. Consider tuning the authentication cache and LDAP sizes.
   2. Test the relative performance of disabling horizontal security attribute propagation.
9. If using EJBs, consider tuning the ORB such as -Dcom.ibm.CORBA.ConnectionMultiplicity, -Dcom.ibm.CORBA.FragmentSize, and -Dcom.ibm.CORBA.MaxOpenConnections.
10. If none of the Intelligent Management or Intelligent Management for Web Server features are used nor planned to be used, set LargeTopologyOptimization=false to reduce unnecessary CPU usage and PMI overhead.
11. Review logs for any errors, warnings, or high volumes of messages, and use -Dcom.ibm.ejs.ras.disablerasnotifications=true if you're not listening to JMX log notifications.
12. Monitor, at minimum, response times, number of requests, thread pools, connection pools, and CPU and Java heap usage using TPV/PMI and/or a third party monitoring program.
13. Upgrade to the latest version and fixpack of WAS and Java as there is a history of making performance improvements over time.
14. Consider running with a sampling profiler such as Health Center for post-mortem troubleshooting.
15. If using Dynacache replication:
    1. If using memory-to-memory HTTP session replication, weigh whether the costs and complexity are better than simple sticky sessions with re-login, or consider using a linearly scalable external cache provider, or the Dynacache client/server replication model.
    2. Install and use the Cache Monitor sample application to watch cache hit rates and cache exhaustion.
    3. If using SHARED_PUSH replication, consider using SHARED_PUSH_PULL to reduce replication volume.
16. If the application writes a lot to SystemOut.log, consider switching to binary HPEL for improved performance.
17. Review the performance tuning topic in the WAS traditional documentation.

For details, see the WAS traditional chapter.

Additional Recipes

• General WAS traditional Performance Problem
• Large Topologies Recipe
• Request Metrics Recipe
• Tune a Thread Pool
• HTTP Sessions Recipe
• Security Recipe
• Connection Pool Hangs in createOrWaitForConnection
• Threads in socketRead0 in JDBC calls
• Threads in java.io.FileOutputStream.writeBytes
• Logging PMI Data
• Logging Custom PMI Data with Dynacache

Previous Section (HotSpot Mission Control Enable at Startup) | Next Section (General WAS traditional Performance Problem) | Back to Table of Contents