Send() too slow

[jbmuser]

Hi,

I think with latest HornetQ 2.0.0.GA I am not getting the speed I used to get for send() in BETA version. I understand that there are a few default configurations changed after BETA but I am trying to figure out the suitable configuration to get a fairly good speed and reliability.

I am sending Durable messages with AUTO_ACK

From the user manual, I see that following are the three parameters which affects send() speed

- journal-sync-non-transactional - Default true

- block-on-durable-send - Default true

- block-on-acknowledge - Default false

Below are the 4 different combinations I tried. Send speed varied from ~40 to ~2300 msgs/s. Also, receive was faster than  send (which was not teh case with earlier versions). Is there any parameter I am missing?

Out of the box (All default settings)
----------------------------------------------
SEND 42.28866240960799 msgs/s
RECV 5291.005291005291 msgs/s

SEND 42.707666026051676 msgs/s
RECV 4901.9607843137255 msgs/s

SEND 42.17451815613007 msgs/s
RECV 4219.4092827004215 msgs/s

After <journal-sync-non-transactional>false</journal-sync-non-transactional>
------------------------------------------------------------------------------------------------------------------
SEND 781.8608287724785 msgs/s
RECV 3125.0 msgs/s

SEND 793.6507936507936 msgs/s
RECV 1436.781609195402 msgs/s

SEND 833.3333333333334 msgs/s
RECV 4878.048780487805 msgs/s

SEND 925.0693802035153 msgs/s
RECV 3703.703703703704 msgs/s

SEND 1104.9723756906078 msgs/s
RECV 2538.0710659898477 msgs/s

After <journal-sync-non-transactional>false</journal-sync-non-transactional> and <block-on-durable-send>false</block-on-durable-send>

--------------------------------------------------------------------------------------------------------------------------------------
SEND 2398.0815347721823 msgs/s
RECV 3649.6350364963505 msgs/s

SEND 2188.1838074398247 msgs/s
RECV 3460.2076124567475 msgs/s

SEND 2309.4688221709007 msgs/s
RECV 3558.7188612099644 msgs/s

SEND 2061.8556701030925 msgs/s
RECV 1851.851851851852 msgs/s

After <journal-sync-non-transactional>false</journal-sync-non-transactional> and <block-on-acknowledge>false</block-on-acknowledge>
-----------------------------------------------------------------------------------------------------------------------------------

SEND 802.5682182985554 msgs/s

RECV 2816.901408450704 msgs/s

SEND 812.3476848090983 msgs/s
RECV 1314.060446780552 msgs/s

SEND 610.8735491753207 msgs/s
RECV 4098.360655737704 msgs/s

SEND 856.898029134533 msgs/s
RECV 3134.796238244514 msgs/s

[timfox]

This all depends on what level of reliability you require.

If you want to be sure that your persistent messages are guaranteed on storage by the time send() returns then you need to send blocking and sync-non-transactional to true - this is the default setting.

Performance is then limited by your hardware.

A normal disk can do maybe 100, 150 syncs per second, you may get higher with AIO - this is hardware limit, nothing to do with HornetQ.

Expensive disks with battery backed caches can sustain a higher rate.

Also RAID arrays, and SAN boxes can because of striping.

If you're doing tests on a laptop / desktop remember this is not representative of server performance.

[jbmuser]

Tim, Thanks  for the quick response. The results I mentioned earlier are in our DEV env, but we will have our data folder on SAN in our production env, So I think setting sync-non-transactional to true or false wouldn't make much difference in my PROD env right? (Assuming that SAN takes care of the I/O overhead)

Thanks

Bijith

[timfox]

I've no idea what the write latency of your SAN is, you'd have to test it.

Bear in mind, that measuring the performance of single sends is rarely a good measure (I have discussed this on other threads too).

Most applications don't just have one connection sending/consuming - they have many connections doing so in parallel, so the overall throughput would be much higher. HornetQ scales very well compared to other messaging providers.

BTW - don't use NFS on your SAN! (That would be NAS really)