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), the maximum nursery size (-Xmn) and enable verbose garbage collection and review its output with the GCMV tool.
  3. Depending on which application components are used, ensure that the relevant thread pools are not consistently saturated (e.g. WebContainer, ORB.thread.pool, SIBJMSRAThreadPool, WMQJCAResourceAdapter, etc.).
  4. If using databases, connection pools should not be consistently saturated. Tune each pool's Maximum connections. <connectionManager maxPoolSize="X" />. Also consider tuning each the statement cache size, isolation level, purge policy, and test with globalConnectionTypeOverride=unshared.
  5. 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.
  6. If using HTTP session database persistence, tune the write frequency.
  7. Consider reducing the default Hung Thread Detection threshold and interval which will print a warning and stack trace when requests exceed a time threshold.
  8. If using security, consider tuning the authentication cache and LDAP sizes.
  9. If Single Sign On (SSO) is enabled, test whether performance is better with web inbound attribute propagation enabled (default) or disabled.
  10. If possible, configure and use servlet caching/Dynacache.
  11. If using EJBs, consider tuning the ORB such as -Dcom.ibm.CORBA.ConnectionMultiplicity, -Dcom.ibm.CORBA.FragmentSize, and -Dcom.ibm.CORBA.MaxOpenConnections.
  12. If using TLS, set -DtimeoutValueInSSLClosingHandshake=1.
  13. Review logs for any errors, warnings, or high volumes of messages, and use -Dcom.ibm.ejs.ras.disablerasnotifications=true if you're not using JMX log notifications.
  14. 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.
  15. Upgrade to the latest version and fixpack of WAS and Java as there is a history of making performance improvements over time.
  16. Consider setting Unlimited persistent requests per connection to maximize the lifetime of keep-alive sockets.
  17. If the applications don't use resources in META-INF/resources directories of embedded JAR files, then set com.ibm.ws.webcontainer.SkipMetaInfResourcesProcessing = true.
  18. Consider enabling the HTTP NCSA access log with response times for post-mortem traffic analysis.
  19. Consider running with a sampling profiler such as Health Center for post-mortem troubleshooting.

For details, see the WAS Traditional chapter.

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