Last October IBM announced a free version WebSphere based on Apache Geronimo, called WebSphere Application Server Community Edition. They’ve just released a minor upgrade, version 126.96.36.199, and updated the developerWorks introductory guide accordingly.
Basically, WAS CE is a J2EE 1.4 Web and EJB container which integrates the integration done by Geronimo of many Apache subprojects into a single package. It’s useful for getting an enterprise Java development and deployment environment up and running fast without having to put all the pieces together yourself. As a free app server, it also lowers barriers for small businesses and non-profits (and the freelancers who support them) to take advantage of J2EE.
It seems that IBM is promoting it quite a bit this week, and have launched an odd ad campaign over at SourceForge (I challenge you to find the only two instances of “IBM” on that page).
If I have time this weekend, I think I’ll give it a test drive and see if I can shoehorn PHP in there somewhere. That would be a truly useful development environment.
On a related note, WAS 6.1 was announced the day after I finally installed WAS 6.0 on one of the department servers. I love when that happens.
An application launched recently handled its biggest traffic spike in stride. No timeouts, no delays, and no application errors so far.
Fortunately, many of the standard tricks for optimizing WebSphere application performance are common sense. For example:
- 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?
After noticing a slight uptick in hits to a document on my own server from my article on Pairing J2EE with PHP to implement a common Web application infrastructure, I discovered that the article was linked from Slashdot this weekend. Not the main page unfortunately, but the Developer subsection. Cool nonetheless. :)
The article argues that while PHP and WebSphere are generally considered competitors, they can work together to support a common type of application. The article covers the roles of a web application, where PHP and WebSphere fit in, and how to install them together with Apache and DB2 on a Linux server. I also provided a sample application as a proof of concept. The example code consists of a J2EE Struts application which serves as a content management system to a PHP-driven public website.