Table of Contents
Advertisement
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
Advertisement
Table of Contents
Troubleshooting
