WebSphere application optimizations

An application launched recently handled its biggest traffic spike in stride. No timeouts, no delays, and no application errors so far.

It was optimized according to the general principles in this Redbook and the WebSphere InfoCenter. Load testing was done with Apache JMeter.

Fortunately, many of the standard tricks for optimizing WebSphere application performance are common sense. For example:

  • Static file serving should be disabled. The front end HTTP server should serve all non-servlet resources; images, CSS, and JavaScript.
  • Reloading should be disabled. This setting prevents the Web container from checking if any changes have been made to JSPs since it last accessed them and then recompiling them.

Additionally, these tweaks boost performance considerably:

  • Caching JNDI lookups for the data source and mail session. An earlier generation of the code didn’t do this, and even though it used a database connection pool, each call to get a connection resulted in a network operation to find that pool. Ouch.
  • Guarding the logging framework. When a debugging flag is off, writing to the out and error streams for all but the most severe errors is cut off, saving lots of I/O.

And RAD helped spot the following performance pitfalls, along with providing input on internationalizing Strings in the Java code.

  • Use of String concatenation in loops.
  • Instantiating collections with an initial capacity.
  • Making sure session objects implement Serializable, to be passed among a cluster of application servers.

There were of course other optimizations, such as static content caching, and there are others that should be considered, such as stored procedures. Logging too, is a place that can benefit from using a standard tool or AOP.

What WebSphere application optimizations have worked best for you? Any hidden Java traps you’ve learned to look out for?

  

Leave a Reply