The Volano Report: Which Java platform is fastest, most scalable? A JavaWorld exclusive!

Speed and scalability are the crucial elements for the successful deployment of a Java server platform, as any Java software vendor can attest. But most administrators possess neither the resources nor the time to test the various server-side Java platforms on the market. JavaWorld therefore turned to Volano and the VolanoMark 2.1 benchmark for answers.

The tests presented in this report look at the performance and network scalability of ten Java virtual machines on six operating systems using a common Intel hardware platform running VolanoMark 2.1. VolanoMark attempts to answer two questions about Java virtual machines used in network server environments -- especially those environments involving a large number of active socket connections:

Is it fast?

Does it scale?

VolanoMark isn't a Java virtual machine test. It's a Java platform test. It allows you to take one set of Java class files and use them to evaluate an entire Java system, including the Java virtual machine, the operating system, the hardware, and the network. Each of the tests in this article was executed on identical Intel hardware, providing an answer to the question our customers ask most -- Which operating system and Java virtual machine will provide the best Java server platform for my Intel box?

Unlike Java support for applets on the client side (where two virtual machines -- those provided by Microsoft and Netscape in their respective Web browsers -- dominate), the leaders in Java on the server side change monthly. Nowhere is that more apparent than for Intel-based systems, which provide dozens of Java VM alternatives. Volano customers can and do switch overnight from one Java virtual machine to another -- or even from one operating system to another -- in order to gain the best performance or network scalability from their Java applications.

What is VolanoMark?

VolanoMark is a 100% Pure Java server benchmark characterized by long-lasting network connections and high thread counts. In this context, long-lasting means the connections last several minutes or longer, rather than just a few seconds. The VolanoMark benchmark creates client connections in groups of 20 and measures how long it takes for the clients to take turns broadcasting their messages to the group. At the end of the test, it reports a score as the average number of messages transferred by the server per second. Its results have accurately predicted the real-world Java performance and scalability of our VolanoChat product line for more than two years.

Furthermore, VolanoMark seems to hit Java platforms where it hurts the most, not only creating a large number of active socket connections and threads but forcing the system to constantly switch among them all. The resulting scores are dominated by several factors:

Whether the Java virtual machine uses a just-in-time compiler (JIT)

Whether the Java virtual machine uses native threads

How many threads per process are supported by the operating system

How many network connections per process are supported by the operating system

VolanoMark 2.1 is available as a free download from Volano's Web site. (See the Resources section below.)

Is it fast?

Each time I run a set of VolanoMark tests against the latest batch of Java virtual machines I find some surprises, and this time is no exception. IBM now dominates VolanoMark performance, whether on Windows NT 4.0 or on its new OS/2 Warp Server for e-business. IBM's Java virtual machine for Windows NT is a remarkable 20 percent faster than the alternatives from Microsoft and Sun. On OS/2 Warp Server it even beats Tower Technology's TowerJ static compiler, showing that it is possible for normal Java virtual machines to surpass native performance, even if that's not yet happening on the same operating system.

PULLQUOTE: BLUE RIGHT Each time I run

a set of VolanoMark

tests I find surprises,

and this time is

no exception. :END_PULLQUOTE

The performance of Tower Technology's latest TowerJ 2.2.7 is still superb, as should be expected from a static compiler. TowerJ takes Java class files and converts them into C source code, which it then compiles into a native executable program. TowerJ 3.0, due for release in March, can dynamically load Java class files in both their original form and in their native TowerJ-compiled form. But unlike all the other Java virtual machines shown here, TowerJ isn't free. (See Resources for the pricing structure.)

Microsoft's and Sun's Java VMs on Windows both fall right in the middle of the pack, with Novell's NetWare Java VM right behind them. Sun's JDK 1.2 [aka the Java 2 platform --editor] on Solaris executes at about half the speed of the top performers, but once you discover its network scalability scores below, you won't care!

The Blackdown Java-Linux port now has a good just-in-time compiler called TYA, which gives it roughly a 50 percent performance improvement over its score without TYA. The latest release of the FreeBSD Java VM is very stable but suffers in performance from its lack of a just-in-time compiler.

Transvirtual's Kaffe OpenVM holds a lot of promise and even convinced a panel of 21 judges that it's the Best Virtual Machine. Unfortunately, that's not a conclusion I can share based on my own tests. For more than a year, I have been unable to run VolanoMark with Kaffe on several different operating systems. I'm still hopeful, however, since Kaffe holds the best promise of providing Java support for some non-Intel Linux systems, such as those from Cobalt Networks.

Run rules

The performance tests were executed with the following commands on a local loopback connection, using the heap size options shown below where possible:

Server:

java -ms8m -mx64m COM.volano.Main

Client:

java -ms8m -mx64m COM.volano.Mark -count 100

See the COM.volano.Mark command synopsis for a complete description of all options.

The operating system was rebooted before each set of tests for a particular Java virtual machine, and the first test result was discarded. The server side was restarted before each run of the client benchmark. The final score is the average of the best two out of three subsequent results.

Results

Scores are the throughput of the server in messages per second. Bigger numbers are faster. See the "Environments" section for details on the hardware platform, operating systems, and Java virtual machine environments.

Table 1. VolanoMark 2.1.2 local performance test, measuring throughput in messages per second. The final score is the average of the best two out of three results. All tests ran identical copies of VolanoMark 2.1.2 on identical hardware.

Notes:

Received "java.net.SocketException: Bad file number" 36 times on the third run, but the test completed successfully.

Failed with "java.net.SocketException: Unimplemented socket option" when the server called Socket.setSoTimeout. Although the latest Kaffe build supports socket timeouts, it still fails to run VolanoMark.

Does it scale?

The fundamental problems with Java performance for Volano's products were solved back in the fall of 1997 with the release of Sun's JDK 1.1.3 on Solaris 2.6 and Microsoft's Internet Explorer 3.0 Java VM for Windows. Granted, there's no such thing as too fast, but even FreeBSD and Linux have Java support fast enough for all but the most demanding Java server applications.

Much more interesting is what happens to all that speed when we increase the number of simultaneous connections to the Java application. In my previous VolanoMark article for JavaWorld, I tested a dozen Java platforms for their performance in handling 100 to 900 concurrent connections. This time I pushed that number up to 2,100 connections. As you can see from the table below, there's still plenty of room for improvement.

Only two out of the ten Java platforms even survived the test, and only one survived without errors. Sun's JDK 1.2 on Solaris 7, still an early access release, finally shows it's possible to handle large numbers of connections to a single Java application without destroying performance (and without any errors). In fact, Sun's performance at 2,100 connections is only 23 percent below its performance at 300 connections!

PULLQUOTE: BLUE LEFT Only two out of the

ten Java platforms

even survived the test,

and only one survived

without errors. :END_PULLQUOTE

IBM also provided some surprises, breaking past VolanoMark's 1,000-connection barrier on Windows NT, which has held back Sun and Microsoft for the past two years. I've been asking IBM how it did that ever since I first saw the results, and the company agreed to disclose the not-so-secret secret (see sidebar). Microsoft and Sun, take notes.

IBM's JDK 1.1.7 on OS/2 Warp Server for e-business died after 600 concurrent connections because of a bug in its uniprocessor kernel that prevented the Java VM from using high virtual memory. IBM says the problem will be fixed in the final release of OS/2 Warp Server for e-business, allowing for at least 1,100 concurrent connections to a single Java application process.

TowerJ and the Blackdown Java-Linux port were unable to break past the Linux kernel's default limit of 256 file descriptors per process. For my previous VolanoMark article, I rebuilt the Linux kernel to allow up to 1,024 file descriptors per process only to discover that neither TowerJ 2.1.2 nor Blackdown JDK 1.1.6 took advantage of the change. The new Linux version 2.2 kernel should provide some relief in this area.

The FreeBSD Java port, along with the FreeBSD operating system, can easily handle up to 2,048 file descriptors per process, but its relatively poor performance makes attempts at anything greater than 600 connections unbearable. A good just-in-time compiler would solve that problem.

Novell's NetWare 5 Java VM, on the other hand, seems to be limited only by the amount of real memory on the system, although I was unable to obtain results above 1,500 concurrent connections with the 256 MB of RAM on my test system.

Run rules

The network scalability test was executed with the following commands over an isolated 10-Mbps Ethernet connection with a 10-Mbps hub, using the heap and stack size options shown below where possible:

See the COM.volano.Mark command synopsis for a complete description of all options.

The client test driver was executed under the IBM JDK 1.1.7 Java virtual machine using Windows NT 4.0 on a 200-MHz Intel Pentium Pro with a 256-KB L2 cache and 256 MB of RAM. The operating systems on both sides were rebooted before each set of tests for a particular Java virtual machine. The VolanoMark server was not restarted between client test runs except where noted.

Results

Scores are the throughput of the server in messages per second based on the total number of concurrent connections. Bigger numbers are faster. See the "Environments" section for details on the hardware platform, operating systems, and Java virtual machine environments.

300

600

900

1200

1500

1800

2100

Figure 2. VolanoMark 2.1.2 network scalability test, measuring throughput in messages per second based on the number of concurrent connections.

Table 2. VolanoMark 2.1.2 network scalability test, measuring throughput in messages per second based on the number of concurrent connections. All tests ran identical copies of VolanoMark 2.1.2 on identical hardware. The Limit is the maximum number of simultaneous VolanoMark connections possible (shown as an estimate when preceded by ~).

Notes:

Failed with "java.lang.OutOfMemoryError". To work around the problem, see below.

Failed with "java.net.SocketException: accept: Invalid argument".

Failed on the first try at 1,800 and 2,100 connections with "java.net.SocketException: Socket read failed: 10055" and "java.net.SocketException: Connection shutdown". Restarted the server and it worked on the second try.

Took too long to complete at 1,800 connections (thrashing).

Failed with "java.net.SocketException: Invalid argument".

Failed with client dead session timeouts.

PULLQUOTE: BLUE RIGHT Just enter one command

to quadruple the number

of threads each

Java virtual machine

can handle. :END_PULLQUOTE

The stack reserve

As IBM has demonstrated, both Sun and Microsoft have artificially crippled the connection scalability of their Java virtual machines on Windows NT by shipping them with the default stack reserve of one MB per thread. Microsoft long ago changed the stack reserve of its own Internet Explorer 4.0 Web browser and Internet Information Server 4.0 Web server, following the "changed standard for all Windows NT system executables." (See the Resources section below.) Why it didn't apply the same change to its Java VM, or why Sun failed to pick up the change for its Windows NT port, is unclear to me. In any case, it's now time for them to follow IBM's lead and make this simple, but important, change.

You can make the change yourself if you buy the Microsoft Visual C++ development environment and use the Microsoft Binary File Editor. Just enter "editbin /stack:262144 java.exe" or "editbin /stack:262144 jview.exe" on the command line to quadruple the number of threads each Java virtual machine can handle.

After modifying the size of the stack reserve on the Microsoft and Sun Java virtual machines on Windows, I obtained the results shown below:

Table 3. VolanoMark 2.1.2 network scalability test of the Sun and Microsoft Java virtual machines for Windows NT after reducing the stack reserve from 1 MB to 256 KB per thread. Throughput is reported in messages per second based on the number of concurrent connections. All tests ran identical copies of VolanoMark 2.1.2 on identical hardware. The Limit is the maximum number of simultaneous VolanoMark connections possible (shown as an estimate when preceded by ~).

Notes:

Failed on the first try at 1,500 connections with "java.net.SocketException: Connection reset by peer" on client side. Restarted the server and it worked on the second try.

Conclusion

If I had my way, there would be only one chart in this report, but I guess that would make for a very short article. I believe the best single test for determining the best Java server platform is to compare the performance at a single high connection count. With this test, we have a clear winner:

Java platform

Score at 2,100 connections

Sun JDK 1.2 Solaris

Sun JDK 1.2 Windows

IBM JDK 1.1.7 Windows

Microsoft SDK 3.1 Windows

459

Figure 3. VolanoMark 2.1.2 network scalability test at 2,100 concurrent connections, measuring throughput in messages per second. All tests ran identical copies of VolanoMark 2.1.2 on identical hardware. Only Java VMs that passed the test are shown; the Sun and Microsoft Java VMs for Windows required a reduction in their stack reserve in order to pass the test.

After seeing Microsoft's Java VM lead the pack in Java server performance and scalability for so long, I had started to think the other Java vendors would never catch up. It seems I greatly underestimated IBM's and Sun's ability to meet the challenge!

John Neffenger is the founder and chief
technology officer of Volano LLC. He is the author of VolanoChat, a
Web-based chat solution written in 100% Pure Java on both the
client and server side. Volano has sold more than 500 server
licenses in 33 countries around the world, with its largest
customer averaging more than 69,000 hours of active connections to
more than 134,000 chat visitors per day. Prior to his role at
Volano, John was a software developer at IBM Corp., working on
Taligent's CommonPoint Application Development Toolkit for OS/2
Warp. Before his assignment at Taligent, John worked in Palo Alto,
CA, and Rome, Italy, on IBM's Open Systems Interconnection protocol
stack. John has a BA in Mathematics from Northwestern University.