After working all weekend on some load testing with JBoss (thanks to the JBoss Group, LLC) - we came to a few conclusions. The IBM SDK 1.4.0 breaks remarkably quickly under load - for ECperf 1.1 the JBoss/IBM JVM hit 100% CPU at txRate=3 and subsequently failed response times whereas the Sun JDK broke at txRate=9. It seems like the IBM JVM works the CPU a bit harder than the Sun JVM.
All JVMs appear to manage the heap poorly (IMHO) - it's done on what seems to be a lazy cycle where a predetermined watermark must be hit before the GC starts shrinking the VSZ/RSS in Linux - you can monitor this during an ECperf test and watch as the memory usage ramps up and then drops in a sawtooth kind of pattern. The IBM SDK does support an alternative better heap management policy (-Xgcpolicy:optavgpause), but it is at the expense of throughput. We've still got a few issues to sort through but there are some base ideas on what we have experienced. We're also working on a few issues with RedHat 9, SMP and JVMs but that is another story. The biggest issue for people upgrading to RedHat 9 who are using IBM or BEA JVMs is the new threading library known as NPTL. It gives you floating stacks and theoretically better SMP support. However, it appears that the aforementioned JVMs still expect the old "Linux Threads" support and break with the new thread library/glibc. So just something of which to be aware. With the IBM SDK, you can fool So how does IBM SDK 1.4.1 come into the picture? Well, it seems to bring a few important improvements. For those who have been following our performance information gathered in http://www.amitysolutions.com.au/downloads/JBoss-3.2.0_optimizations.pdf and http://www.amitysolutions.com.au/downloads/JBoss_code.pdf. As a comparison with the existing data: Average application response time: Previous lowest average was 108 ms and now 105 ms under 1.4.1. There does not appear to be as many or as large a set of fluctuations under 1.4.1. The median does not appear to have changed. Remote lookups and remote EJB calls from an external VM has dropped by 3% from the previous lows. However, the biggest immediately noticeable change is in the memory management. The footprint of the preceding VSZ/RSS has been about 176M/122M under the same test conditions. The 1.4.1 SDK delivers 139M/115M. JBoss under the IBM SDK 1.4.0 started up in about 4m40s on the test system. With IBM SDK 1.4.1, this is cut to 2m20s. Finally, although there is no formal support for NPTL from IBM (i.e. if it breaks, you get to keep both bits), they do acknowledge that the new SDK is known to run with the new NPTL threading library on RedHat 9 (only). So there are a few good reasons to upgrade I guess. I have noticed that the SDK may have tightened up some things in the collection management. The following error appears in a JBoss 3.2.0 runtime: 2003-07-15 15:15:30,544 ERROR [STDERR] java.lang.NullPointerException 2003-07-15 15:15:30,562 ERROR [STDERR] at java.util.LinkedList$ListItr.previous (LinkedList.java:523) 2003-07-15 15:15:30,563 ERROR [STDERR] at org.jboss.resource.connectionmanager. InternalManagedConnectionPool.removeTimedOut(Unknown Source) 2003-07-15 15:15:30,563 ERROR [STDERR] at org.jboss.resource.connectionmanager. IdleRemover$1.run(Unknown Source) I'll eventually get around to looking at it. Anyway, hope this information is of use. JonB
smime.p7s
Description: S/MIME cryptographic signature
