64 bit performance tuning tips

Applications that run on the WebSphere Application Server 64-bit version can see significant performance gains if they can leverage the support for large heaps. To exploit the large heap, you can use dynamic cache in WebSphere Application Server. The process to tune dynamic cache remains the same for the 64-bit version as for the 32-bit version. However, all memory references are also 64-bit wide on the 64-bit version, which is twice the size of memory references on the 32-bit version. This size difference causes an increase in the memory requirements of the applications when deployed on 64-bit, as compared to 32-bit.

Web Container Transport channel settings

The Web Container transport channel lets you configure the write size of the buffer. In the Tunning Transport Channel service, we covered the basics of what is channel service. In that page click on the TCP Inbound Channel link and you will get this page




If multiple writes are required to handle responses to the client, change the value specified for the Write buffer size parameter to a value that is more appropriate for your clients. The Write buffer size parameter controls the maximum amount of data per thread that the Web container buffers before sending the request on for processing. The default value is 32768 bytes, which is sufficient for most applications. If the size of a response is greater than the size of the write buffer, the response is chunked and written back in multiple TCP writes. If you need to change the value specified for this parameter, make sure the new value enables most requests to be written out in a single write. To determined an appropriate value for this parameter, look at the size of the pages that are returned and add some additional bytes to account for the HTTP headers.

Enabling Keep Alive in WAS

The HTTP Channel service lets you configure behavior of the HTTP Channel, things like if you want to keep the HTTP connective alive In the Tunning Transport Channel service, we covered the basics of what is channel service. In that page click on the HTTP Inbound Channel link and you will get this page




The Use Persistent (keep-alive) connections settings controls whether or not connections are left open between requests. Leaving the connections open can save setup and teardown costs of sockets if your workload has clients that send multiple requests. THe default value is true and which is optimal setting in most cases.If your clients only send single requests over substantially long periods of time, it is probably better to disable this option and close the connections right away rather than to have the HTTP transport channel setup the timeouts to close the connection at some later time.

TCP Channel tunning

You might want to tune TCP Channel related settings if say your backend is slow and the CPU is unused. In the Tunning Transport Channel service, we covered the basics of what is channel service. In that page click on the TCP Inbound Channel link and you will get this page




The most important setting on this page is the thread pool assigned to the channel. Each TCP transport channel is assigned to a particular thread pool. Thread pools can be shared between one or more TCP transport channels as well as with other components. The default settings for a TCP transport channel is to have all HTTP based traffic assigned to the WebContainer thread pool and all other traffic assigned to the Default thread pool.

Tune the size of your thread pools. By default, a thread pool can have a minimum of 10 threads and a maximum of 50 maximum threads. To adjust these values, click on Thread pools < threadpool_name and adjust the values specified for the Minimum Size and Maximum Size parameters for that thread pool. Typical applications usually do not need more than 10 threads per processor. One exception is if there is some off server condition, such as a very slow backend request, that causes a server thread to wait for the backend request to complete. In such a case, CPU usage is usually low and increasing the workload does not increase CPU throughput. Thread dumps show nearly all threads in a call out to the backend resource. If this condition exists, and the backend is tuned correctly, try increasing the minimum number of threads in the pooll until you see improvements in throughput and thread dumps show threads in other areas of the runtime besides the backend call. The setting for the Grow as needed parameter should not be changed unless your backend is prone to hanging for long periods of time. This condition might indicate that all of your runtime threads are blocked waiting for the backend instead of processing other work that does not involve the hung backend


Leave the Maximum open connections parameter set to the default value. This parameter controls the maximum number of connections that are available for a server’s use. It should be left at the default value of 20000, which is the maximum number of connections allowed

Tuning transport channel services

The transport channel service manage client connections and I/O processing for HTTP and JMS requests. These services provide a highly scalable foundation to WebSphere Application Server request processing. Java NIO based architecture has limitations in terms of performance, scalability and end user usability. Therefore, integration of true asynchronous I/O is implemented. This implementation provides significant benefits in usability, reduces the complexity of I/O processing and reduces that amount of performance tuning you have to perform.Changing the default values for settings on one or more of the transport channels associated with a transport chain can improve the performance of that chain.

I copied this diagram from IBM Redbook, it explains how the Transport channel service works.




You can access the the transportation related configuration in WAS Admin Console by going to Servers - server_name -> Web Container settings - Web Container transport chains, then select WCInboundDefault, which is the virtual host for handling all the requests to web application on that server.



As you can see there is a hyper link for configuring settings related to each of the three channels

Tuning Java virtual Machine

WebSphere application server is a Java based server and requires a Java virtual machine to run the server and applications deployed on it. Tunning underlying Java virtual machine can play a major role in tuning performance. The WebSphere Application Server runs on different JVMS. In most of the cases it is IBM JDK, but on Solaris it is Sun JDK,.. What parameters you can use and the syntax to set there values depends on the type of JVM your tuning.

The parameters that can be used for tuning JVM can be divided into following three types and you can tune all three of them from WAS Admin Console this page

Java memory or heap tuning: Java memory or heap controls the amount of memory that is allocated for use by individual application server instance. You can change the JVM both initial and maximum heap size. Increasing this parameter increases the memory available to the application server, and reduces the frequency of garbage collection. Increasing this setting can improve server response time and throughput. However, increasing this setting also increases the duration of a garbage collection when it does occur. This setting should never be increased above the system memory available for the application server instance. Increasing the setting above the available system memory can cause system paging and a significant decrease in performance. Tuning value of initial heap size reduces the overhead of garbage collection, which improves server response time and throughput. You can change the initial or maximum heap size by changing value of "Initial heap size" and "Maximum heap size" fields.

Garbage collection tuning: When the JVM cannot allocate an object from the current heap because of lack of contiguous space, the garbage collector is invoked to reclaim memory from Java objects that are no longer being used. Each JVM vendor provides unique garbage collector policies and tuning parameters. You can set the garbage collection policy by passing it as command line parameter using -X option suitable for your JVM. The generational garbage collection is the best performing garbage collection policy, Also by default, the JVM unloads a class from memory whenever there are no live instances of that class left. Class unloading can degrade performance. Turning off class garbage collection eliminates the overhead of loading and unloading the same class multiple times.

Start up versus runtime performance optimization: In some environments, such as development environment, it is more important to optimize the startup performance of your application server rathar than the runtime performance. In production or test environment it is more important to optimize the runtime performance than startup performance.The Java JIT compiler has a big impact on whether startup or runtime performance is optimized. The initial optimization level that the compiler uses influences the length of time it takes to compile a class method, and the length of time it takes to start the server. For faster startups, you should reduce the initial optimization level that the compiler uses. However if you reduce the initial optimization level, the runtime performance of your applications might be degraded because the class methods are now compiled at a lower optimization level. The share classes option of the IBM Java 2 Runtime Environment (J2RE) Version 1.5.0 lets you share classes in a cache. Sharing classes in a cache can improve startup time and reduce memory footprint. Processes, such as application servers, node agents, and deployment managers, can use the share classes option.