Checklist
- JDBC Connection Pools & Prepared Statements
- WebContainer Thread Pools
- JVM Heap Sizes & Generational garbage collection
JDBC Tuning
The initial WebSphere JDBC pool size is only 10 connections maximum. This is very small and should be increased for all installations. Note that each application server, and thus each component, has its own connection pool. In addition, each component also maintains its own connection pools to the Homepage database for both Search and News functionality. Each will need to be tuned separately. Also, ensure that the backend DB will accept the total number of connections from all JDBC pools.
It is recommended that this value be to 50 after installation and tune as required by your workload. This includes the Homepage database connection pool for the Homepage application. For other components, 10 to 20 JDBC connections are enough for the Homepage pools.
As a general rule, the connection pool settings do not need to be larger than the Web Container thread pool setting. If they are, additional connections will never be used because no end users will be able to connect to WebSphere.
In addition, the prepared statement cache size is also too small. Setting the cache to 100 statements should be adequate for all workloads. The exception to this was some Oracle measurements, where to keep Oracle from running out of memory, this was lowered to 50.
The effect of these settings may be monitored either by enabling the IBM Tivoli Performance Monitor or from tracking connection ‘high water marks’ in database snapshots.
WebContainer Tuning
The initial WebSphere WebContainer thread pools is only 50 maximum may be too small. Note that each application server maintains its own thread pool. Each will need to be tuned separately. In general, the value necessary here should be roughly equal to the number of expected hits per second to each application. This value, in turn, will need to be at least as large as the JDBC connection pool.
Users can monitor the actual number of threads being used in the pool by enabling the appropriate performance counters in the IBM Tivoli Performance Monitor.
JVM Tuning
The WebSphere default size of 256MB for each JVM is too small. The maximum heap size should be at least 512MB and may need to be set as high as 1280MB, depending on the load.
It can also beneficial to run with the same minimum heap size as the maximum. This was done during most of the benchmarks to avoid the overhead of JVM memory compaction.
One caveat with running larger JVM sizes is that all the JVMs running on a physical server must fit into the physical memory of the server. As a result, a system that will run all components in separate JVMs could need at least 10 GB of memory just to support the JVMs. This is in addition to the memory needed by the operating system and other system processes.
A critical setting for performance is the generational garbage collector which can be enabled by adding the string -Xgcpolicy:gencon in the generic JVM argument field in the WAS Admin Console.
Another beneficial JVM tuning specific to Profiles was lowering the soft reference threshold from 32 to 16 with -Xsoftrefthreshold16. Profiles creates report to chain data using a cache of SoftRef objects. By default, it will take 32 garbage collection cycles to a reference before the JVM will remove the object from the heap. Depending on the number or profiles in the database, it is possible for this cache to use a significant portion of the total heap if most of the profiles are loaded into the cache. In periods of high load, there may not be enough free space to service all the incoming requests. As a result, there could be large number of GC compaction attempts that do not succeed in freeing much heap since many of the references have been accessed recently. Lowering this threshold lowers the chances of this occurring since objects are more likely to be garbage collected.
Users can enable verbosegc logging and monitor heap use with any of the above settings applied.