JMS File Persistence (Fast) vs JDBC Persistence (Slow)
gobrien Jun 6, 2005 4:53 AMWe have found that using JMS JDBC Peristence takes 6 minutes and half JMS File Peristence takes 2.5 minutes to process our Data:-
Overview
Currently we use JBoss 3.2.3 with our application and we use JMS extensively in our batch processing engine. The Processing components of our Batch engine are in separate Java VM instances and the workload is distributed and queued using JMS. When we first ported to JBoss we evaluated the JMS Persistence technologies available and finalized on using File Persistence. This we found was the most reliable and provided the best overall performance (rolling log was fast, but could never reload the messages after a crash. The messages that are sent through JBoss are ObjectMessages and contain a serialisable Java objects, that vary in size and volume depending on the type of documents that are processed and the engine component that is using JMS, small messages are around 4k and large messages can be several megabytes, but a normal document may be 400k.
JMS File Persistence
Using the currently JBoss 3.2.3 configuration using File Persistence we can process a batch in around 2.5 minutes, this example will create and send around 700 jms messages, 600 of these will be around 400k. The processing of the message in our code is very cpu intensive, so there is not much free CPU resource to be had. When running this test we get an average CPU utilization (on a Dual 3.2Ghz P4 HT) of 95%.
JDBC JMS Persistence
We are trying to port and certify our software on JBoss 4, and have chosen the current release 4.0.2 to perform this conversion. However it seems that version 4 has dropped support for File Persistence, although we have tried JDBC persistence before with 3.2.3 and found it slow, I tried it on 4.0.2, hopping it has improved.
However my findings were similar to before.
JBoss 4.0.2 Oracle JMS Persistence
Running the same test suite, we get an average batch processing time of 6 minutes for Oracle JDBC3 Persistence using the 10g driver, also CPU was running at 45%.
JBoss 4.0.2 Hypersonic JMS Persistence
Hypersonic performed well initially, 2.5 minutes per batch but performance degraded after 40 batches, then it JBoss to run out of memory after processing 140 batches by which time the processing time had reached 10 minutes per batch, also CPU was running at 95%.
JBoss 4.0.2 with File Persistence
Dismayed with these performance, I checked the code and it looked like the File Persistence manager of 3.2.3 would work with 4.0.2, I created a new jbossmq.jar with the org.jboss.mq.pm.file package included. It worked fine and the results we slower than 3.2.3 at 3.5 minutes per batch average, but still much better than the JDBC alternatives.
JBoss 4.0.2 Not an upgrade Option Currently
Running any slower than 3.2.3 will not go down well with our customers, the file based solution has lots of benefits for us (see below), and unless the JDBC option can equal or better the File Persistence we will have to reconsider supporting JBoss. The other Application Servers we use support a File/Non SQL persistence option (Weblogic and WebSphere), we need JBoss to continue to support this persistence method.
Benefits of File Persistence:-
* Performance (at least 2x Faster than JDBC, even with Oracle server on same box, if it?s a remote MS SQL Database JDBC persistence could be many times slower than File Persistence).
* Not having to support and verify the JMS Backbone with each database we support Oracle, DB2 and MS SQL Server.
* Support ? Easy to navigate to dir, to see how many messages are in queues etc.
Were can we go from here?
System: Sun Java 1.4.2_08 Win 2003 Server Oracle 9i H/W CPU 2x3.2GHz P4 HT with RAID5