WebSphere Application Server V7.0: Concepts ... - IBM Redbooks

Starting a JVM with too little memory means that the application must
immediately switch context to allocate memory resources. This will slow down
the server startup and the execution of the application until it reaches the heap
size it needs to run. Conversely, a JVM that can grow too large does not perform
garbage collection often enough, which can leave the machine littered with
unused objects and a fragmented heap that requires compacting later on.
The levels should be adjusted during the testing phase to ascertain reasonable
levels for both settings. In addition, the prepared statement cache and dynamic
fragment caching also consume portions of the heap. You might be required to
make additional adjustments to the heap when those values are adjusted.
Thread pools
Inside the application server JVM separate thread pools are used to manage
different types of workload. Depending on your type of application, appropriate
thread pools require careful planning.
Web container thread pool
The thread pool for the Web container should be closely monitored during initial
load testing and production. This is the most common bottleneck in an
application environment. Adjust the number of threads in the pool too high, and
the system will spend too much time swapping between threads and requests will
not complete in a timely manner. Adjust the number of threads too low, and the
Web server threads can back up and cause a spike in response at the Web
server tier.
There are no hard rules in this space, because things such as the type and
version of Web server and the percentage of requests that require the application
server can impact the overall optimum tuning level. The best guideline is to tune
this setting in repetitive tests and adjust the numbers.
Enterprise JavaBeans container thread pool
TheEnterprise JavaBeans (EJB) container can be another source of potential
scalability bottlenecks. The inactive pool cleanup interval is a setting that
determines how often unused EJBs are cleaned from memory. Set it too low, and
the application will spend more time instantiating new EJBs when an existing
instance could have been reused. Set it too high, and the application will have a
larger memory heap footprint with unused objects remaining in memory. EJB
container cache settings can also create performance issues if not properly
tuned for the system.
Chapter 7. Performance, scalability, and high availability 239