IBM BS029ML Self Help Guide - Page 49

Architecting a minimum of three Web servers is also recommended from the point of view that, if a Web server should fail or be taken out of service in a two-server model, then the remaining server has the potential to become overloaded. Load balancing is most effective with three or more servers in a cluster. As such, applications that require load balancing should ideally be spread across three or more servers. 2.5.7 JVM recommendations One common misnomer is that setting a large JVM heap size improves performance. This is simply not the case. It is strongly advised that the Java maximum heap setting is chosen carefully and then only based on a thorough Java garbage collection (GC) analysis. Remember: If you use a big heap, then garbage collection will be less frequent but much slower, as there is a lot of memory to search through. If you use a small heap, then garbage collection will be more frequent but very fast, as there is less memory to search through. The Java garbage collection (GC) cycle, which is a "stop-the-world" implementation, will prevent the application server from handling loads for a short period of time. All threads are effectively suspended, with the exception of the garbage collection threads, while GC completes to protect the Java heap from corruption. WebSphere Portal Server vertical clustering can be used to ensure that the CPU is able to provide execution time for at least one cluster member server that can handle the load. Since Version 1.3.x, the IBM JVM has supported multiple garbage collection (GC) helper threads to improve performance during the mark phase of GC. A major concern for IBM is when customers configured WebSphere Portal Server with a large JVM heap and a high Web Container thread pool. In keeping with the IBM Proven Performance Tuning Methodology, the recommendation is to reduce the JVM heap and the Web Container thread pool and to distribute the load over additional cluster members. The larger the number of Web Container threads, the higher the number of concurrent requests allowed to enter the Web Container. At some point, however, the number of concurrent threads being processed by the Web Container may overwhelm the ability of the JVM. To prevent such an occurrence, a smaller Web Container thread pool can be used. Pending requests will be queued in the network layer. The rationale behind this recommendation is that smaller discrete cluster members will generally outperform one larger single occurrence, so sharing the load equally guarantees better concurrency. In addition, the benefit from running a single JVM on a large multi-processor machine does not always benefit from all of the resident CPUs. Of course, there are many other factors that influence performance. It should be remembered that adding additional cluster members is the method by which WebSphere and WebSphere Portal Server scales. It is important to mention that garbage collection (GC) is one of the strengths of Java. By taking the burden of memory management away from the application developer, Java applications tend to be much more robust than applications written in non-garbage collected languages. However, this does not mean that the Java developer can totally neglect memory management. Failing to dereference Java objects after use will prevent the Java garbage collector (GC) from freeing the memory back to the Java heap (this constitutes a memory leak). Likewise, fetching large resultsets and placing them into an array, so that they can be passed as a single variable between objects, also has memory implications. Chapter 2. Architecture and planning 35