Extensive experience building J2EE applications in IBM’s WebSphere environment – and mistakes made along the way -- have convinced Candle Corporation Senior Architect Warren Macek that a by-the-book approach isn’t always the best strategy.
“I thought I did everything right, and when I went to production with these applications after they tested great, they ran very poorly,” Macek noted in the ebizQ webinar Best Practices for J2EE Programming and Performance Management, part of the Best Practices for IBM WebSphere Software Series, sponsored by Candle Corp.
Macek provided a long list of tips and best practices.
It began with optimizations such as bypassing the application server when providing static Web pages, using servlets that don’t require Enterprise Java Beans, and only using the HTTP server embedded in WAS 5.0 for testing.
Macek explained how perfectly tuned application servers can be templated into easy-to-control server groups, then cloned on the same (vertical cloning) -- or across multiple (horizontal cloning) – machines to efficiently increase performance.
“(Cloning) is a very slick way of controlling JVM processes running on the app server for your application,” he noted.
Macek outlined the pros and cons of, and differences between the types of cloning, but pointed out that, “In the real world, what I've seen is that most of the time, people do a combination of both vertical and horizontal cloning. They combine the two.
“Normally I start with vertical cloning, get the best throughput I can, then add horizontal cloning, and mirror the two machines, because failover support is key when you're running a full-blown application in production, where you have to have 24/7 uptime.”
Macek then focused in more detail on servlets: their proper size (“under 50 lines of code”), their balance with JSPs (“We like to see one servlet serve up maybe 3, possibly 4 JSP pages”), and the best way to have them acquire static information.
Dynamic Web pages pose a bigger challenge. Single-threaded servlets that must be instantiated for every user create “tremendous overhead” and should be avoided, Macek advised.
And while multi-threaded servlets offer better performance, they also require some precautions – Macek shared with the audience how poor coding on his part temporarily enriched a financial-services user by enabling him to access another’s account. Macek stressed, “If you do multi-threaded modeling, synchronize, and maintain your instance variables local to that piece of code that's necessary.”
-1-