IBM BS029ML Self Help Guide - Page 161

Attention: Incorrectly calculating the various values attributed to the advanced SUN JVM parameters can prevent WebSphere Portal Server from starting up. Always evaluate your parameters in a test or staging environment before undertaking any changes in your production environment. If you experience performance degradation and high %CPU, consider enabling a verbose garbage collection (GC) trace either through the WebSphere Application Server Administrative Console check box or by using the -verbose:gc parameter. Full GC cycles may be indicative of an insufficiently sized Permanent generation and can give rise to long GC times. Enabling parallel garbage collection may help to reduce such times. Note: Performance documentation for the various SUN JVMs is available at: http://java.sun.com/docs/hotspot/index.html 5.2.4 WebSphere resource pools In order to understand how to maximize performance, it is first necessary to understand the WebSphere queuing mechanism. WebSphere implements a componentized architecture, channeling requests through a number of queues. These queues or pools include the Web server (considered even though it is an external component), the application server Web container, the EJB container, data sources, and possibly other connection pooling mechanisms to various custom back-end systems. Each of these resources sustains a queue of requests waiting to use the resource in question. The overall queuing mechanism is designed to converge towards the back end, where resources are deemed more expensive. For example, it is not uncommon for the Web server queue to be configured to handle an inordinately large number of requests. This contrasts to a data source pool, which by nature is more expensive (both in terms of CPU and memory) and thus usually only configured to handle a maximum of 10-20 connections simultaneously. Each queue has the potential to become saturated. There also exists the possibility that if one of the back-end queues saturates, that it will have a knock-on effect, impacting the other queues in front. For example, it is not unusual that if a data source connection pool saturates that the Web container will also eventually overload (simply due to the fact that requests cannot be processed further downstream). This can be particularly confusing when instigating a performance appraisal. In which case, it is recommended that you take a holistic approach to performance tuning and determine which queue saturates first. Tip: One would generally expect to see an increase in %CPU under load when a pool is increased for any given WebSphere Application Server instance. This is the expected behavior, as increasing a resource pool will consume more %CPU as more concurrent throughput is being achieved. However, if the %CPU does not increase after a pool is enlarged when under load, then this usually means there is a bottleneck elsewhere in the system or that the system has reached saturation point. Consideration should also be taken into account that increasing a resource pool by too much may push a problem to somewhere else within the architecture. For example, a problem relating to SQL query concurrency is only shifted to the database if the concerned WebSphere data source is increased. Chapter 5. WebSphere Portal runtime and services 147