HornetQ - low performance in real world scenarion?
mreasy Oct 15, 2009 9:47 AMOur aim was to compare the performance of HornetQ against JBossMQ. To check, if we get at least the same performance as JBossMQ without the need to flood the database with short term data (Oracle: massive redolog / archivelog generation).
We tested the following two combinations:
1.) HornetQ (JBoss 4.05 with embedded HornetQ)
2.) JBossMQ (JBoss 4.05 with embedded JBossMQ (connected to remote Oracle 11 database)
We deployed a simple MBean that acts as MessageProducer.
The following happens during execution:
a.) load an external file (10KB)
b.) setup jms connection/session (non-transacted, auto_acknowledge) + look-up queue
c.) for each iteration:
createObjectMessage
.setObject(filecontent)
send()
d.) close jms resources
We deployed a MessageDrivenBean that acts as MessageConsumer - plain simple onMessage method. Used only to clean up the message queue.
We used the following HornetQ config:
<journal-sync-transactional>true</journal-sync-transactional> <journal-sync-non-transactional>true</journal-sync-non-transactional> <journal-min-files>10</journal-min-files> <journal-compact-min-files>15</journal-compact-min-files>
For reasons of transactional safety, we set "journal-sync=true". We assume, that "journal-sync=false" cannot be used on a production system.
We only measured the throughput (message/sec) of the message sending and decided to use HornetQ from trunk as of 2009-10-14.
Each run was sending 10.000 messages with about 10KB each.
Platform: HornetQ (msg/sec) JBossMQ (msg/sec) ******************************************************************************** WinXP 64bit 20 125 - write cache is on HornetQ data store on local HD: [Hitachi Ultrastar 15K300 (300GB, SAS, 3.5", 15000rpm, 16MB)] Solaris SPARC 35 125 WinXP 64bit 98 125 - write cache is on HornetQ data store on network drive Redhat Enterprise Linux 1200-1600 125 AIO configured HornetQ data store on SAN Redhat with local data store I will post when ready
We have to support Windows and various Unix platforms with our enterprise solution. It should perform well on all these platforms.
Our results on the Windows platform with NIO are not acceptable for us, we expected them to be better using the file journal for persistence.
The question is, if our test was invalid for some reason or if there is someone with better results and could explain how to achieve them.
Doing some micro-benchmarking, revealed that waiting for the response using
sendCondition.await(toWait, TimeUnit.MILLISECONDS);in org.hornetq.core.remoting.impl.ChannelImpl.sendBlocking(Packet) is taking a significant amount of time. Also it seems that this needs to get called multiple times per send. Maybe this may serve as a hint.
Index: src/main/org/hornetq/core/remoting/impl/ChannelImpl.java =================================================================== --- src/main/org/hornetq/core/remoting/impl/ChannelImpl.java (revision 8107) +++ src/main/org/hornetq/core/remoting/impl/ChannelImpl.java (working copy) @@ -262,6 +262,7 @@ long start = System.currentTimeMillis(); + final long responseStart = System.nanoTime(); while (response == null && toWait > 0) { try @@ -283,6 +284,12 @@ start = now; } + final long responseDuration = System.nanoTime() - responseStart; + if (responseDuration > 50 * 1000000) + { + System.out.println("Response:\t" + responseDuration); + } + if (response == null) {
--
Rico Neubauer