Rollout: BEA's WebLogic RealTime 1.1

Direct enough heavy traffic at just about any JavaEE application, and you'll see a pattern: The garbage-collection process kicks in, Microsoft's Task Manager registers a sudden spike in CPU utilization, and your app's performance tanks, with TCP time-outs, longer response times and even dropped connections. Until now, there was no way to fix this. To compensate, you could provision additional capacity, but the underlying problem remained.But BEA Systems has devised a bona fide solution: WebLogic RealTime (WLRT) 1.1 cuts response time and CPU utilization, and dramatically improves performance. WLRT comprises an optimized WebLogic application server and the JRockit Java Virtual Machine (JVM). JRockit's deterministic garbage collection, a dynamic algorithm, removes the long pauses typically caused by collections in Java applications. It improves memory management and limits the time spent on garbage collection.

New Markets For Java

This improvement is so significant that WLRT can make Java technology viable for financial services companies and government agencies, as well as other organizations that are reluctant to move from their C/C++ -based apps for fear of the latency introduced by garbage collection in JVMs. A stock trade held up for even five seconds in a critical situation could result in a huge loss for the trader and, by extension, the broker. Anyone who's tried to wait until the last second to outbid competitors on e-Bay knows that seconds are critical, and it's impossible to predict when garbage collection will kick in next and prevent us from winning something like a Babe Ruth baseball.

Sun, which implements one of the most prominently deployed JVMs, offers four different garbage-collection algorithms, as well as lengthy documentation on how to best tune the JVM for optimal performance. But few IT shops ever dig into the specifics of tuning a JVM, and we end up living with suboptimal performance.

With deterministic garbage collection, BEA's predictive algorithm continuously monitors object status and recycles memory when necessary rather than waiting for a scheduled collection. It also limits the time spent on collection so the typical long pauses experienced under heavy load or continuous use are drastically reduced.At first, we doubted BEA's performance claims for WLRT 1.1. After all, if it were possible to lose the garbage-collection latency, wouldn't Sun have done it already? After testing WLRT 1.1 in several scenarios, we concluded BEA's solution works.

Even better, BEA convinced us WLRT would support just about any JavaEE container--not just those offered by BEA. To test the claim, we picked out a Dell 2850 with dual 2.8-GHz Xeon processors and 1 GB of RAM, installed Windows 2003 Release 2, Service Pack 1 and got down to business. We installed Geronimo 1.1 with Tomcat 5.5.15 and configured it to use WLRT 1.1. To compare performance against Sun's JVM, we used J2SE 5.0 Update 8. We then beat the daylights out of a JSP sample distributed with Geronimo and took notes. We were pleased, and a bit surprised, when memory consumption, CPU utilization, requests per second served and average response times all improved with WLRT. Everything performed better--and more consistently--when Geronimo took advantage of WLRT rather than the latest Sun JDK.

We also wrote some fairly ugly Java code, which used up and discarded memory quickly, and ran it under both JVMs. Before we tuned the Sun JVM, the code would not run at all; it ran out of heap within seconds of starting a run. WLRT had no such issues. The code ran once we tuned the Sun JVM and changed the garbage-collection algorithm, but at a significantly slower rate and with noticeable pauses due to garbage-collection execution. We're convinced that BEA's claims about WLRT 1.1 are valid. Although Sun's JVM could be tuned to perform as well as WLRT 1.1--with substantial effort--we can comfortably say that out of the box, the Sun JVM does not match the performance of WLRT 1.1.

Improvements made possible by JRockit make JavaEE capable of being deployed for soft real-time applications (say, VoIP or live AV streams), but hard real-time applications--those in which spikes in latency cause critical system failure, such as air traffic control systems or pacemakers--may still require the stability of conventional C/C++ applications.Although the list price of $10,000 per CPU for WLRT seems steep--especially when compared to free JVMs from Sun and IBM--the increase in performance may well be worth the cost of acquisition. With consolidation all the rage these days, WLRT 1.1 can offset its cost by increasing server capacity for applications that might otherwise require more than one server and the resulting increases in maintenance, power and licensing costs.

For those who've always been afraid of JavaEE solutions because of JVM issues, WLRT should banish those fears once and for all.

Lori MacVittie is an NWC senior technology editor working in our Green Bay, Wis., labs. She has been a software developer, a network administrator and a member of the technical architecture team for a global transportation and logistics organization. Write to her at [email protected].