WebSphere Application Server A walk in the clouds

Now that cloud and its enabling technologies like application, platform, software virtualization are hot and sexy, I am jumping on the bandwagon too :-) with some specific advice regarding WAS deployments in the cloud.

In order to leverage the full awesomeness of  your WAS virtualized deployment, it is critical to do the following :

Tuning WAS for idleness: WAS system components can sometimes be more chatty than teenagers aka in corporate speak WebSphere schedules timed events to check for system updates and the availability of other servers; keeping the entire infrastructure up-to-date and running flawlessly. There are several configurable timers and options which affect the amount of background processing during idle windows. It is critical to tune these timer threads and system daemons to reduce background processing within the application server. This helps the hypevervisor technology manage the guests better. It allows virtual images to swap in and out, thereby leading to better resource utilization and less over-commit. Follow the recommendations in the document below for tuning WAS, for idleness in dense virtual environments:  http://bitly.com/lC0YQe
http://webspherecommunity.blogspot.com/2011/05/tuning-for-idleness-service.html

Tune the JVM: In order to use Java effectively in the cloud you should avoid over commit, use less and share more.
– Avoid over-commit
  •  Matching scenarios: sandbox, legacy systems
  •  Limits cost savings
– Use Less
   •  Trade off some performance for memory
   •  Classic speed/space trade-off
   •  Easy - Just some Java command line tuning
– Share More
   •  Requires multiple JVMs per Guest OS
   •  Easy – one additional Java command line option  -Xshareclasses

Enable class sharing between JVMs using the -Xshareclasses JVM argument. This reduces the physical RAM usage when running multiple JVMs and improved start-up time. This option is ONLY available on the IBM JDKs. The shared cache contains Application classes, Metadata (JIT data, class file locations, debug, ...) and Ahead-of-time (AOT) compiled code which is shared across JVMs on the same guest OS. Tuning the shared class cache.

Select the right garbage collection policy i.e. optimize for throughput, pause time or short lived objects/web. Correctly set the heap sizes for your JVMs. Remember the maximum heap size setting should be 43% larger than the maximum occupancy of the application. Generally speaking, tune and restrict the JVM heap size to as small a value you can live with.