I have just ran a very simple performance test to compare ActiveMQ 5.9.0 to
some other broker.
This message is rather long but has some surprising and also unexpected
results, so please bear with me and read on...
I have used the following setup:
Broker:
* Virtual Machine with CentOS 6.0 64bit
* 2 virtual CPUs and 6GB RAM
* latest Oracle JVM (1.7.0_45)
* ActiveMQ 5.9.0 (built from source)
* Openwire and AMQP connectors are both configure using NIO
Client:
* Client running on separate VM connected via corporate Gigabit LAN to
broker VM
* Client using the "standard" ActiveMQ JMS client in one test and the
Qpid-amqp-1-0-client-jms library for another test (the qpid-amqp library was
built from source using the latest head with a recent patch)
* The ActiveMQ JMS client was connecting with caching and pre-fetch enabled.
This feature does not exist with the AMQP client library.
The test consists of a very simple scenario:
1. En-queue 1000 messages (1024 bytes message body) in a single threaded
application using a single connection and session
2. After completing step #1, de-queue those 1000 messages in the same single
threaded application using the same connection but with a new session
I measured the time it took to en-queue and de-queue each message using
System.nanoTime() with a resolution of +/- 100 nanoseconds. I essentially
took the time before I called producer.send(msg) and then took the time
immediately after the call returned.
The same measurement was applied with the de-queue - I took the time before
a consumer.receive(timeout) and immediately after.
I configured and measured my ActiveMQ 5.9.0 broker with three different
persistent stores:
1. KahaDB (the default)
2. LevelDB (Java)
3. LevelDB (native via JNI)
I installed the native LevelDB 1.7 Rel2 from the standard CentOS repo.
Since I am particularly interested in performance of persistent messages, I
will only present those results here:
Here are the results using the "native" ActiveMQ client via openwire.
======================================
Persistent Store | en-queue | de-queue
KahaDB | 57.9 ms | 0.3 ms
LevelDB (Java) | 28.6 ms | 0.2 ms
LevelDB (JNI) | 26.3 ms | 0.2 ms
======================================
It is visible that LevelDB seems about 2x faster than KahaDB.
And now comes the surprise, at least to me. Here are the results connecting
with the qpid-amqp-1-0-client-jms library.
======================================
Persistent Store | en-queue | de-queue
KahaDB | 24.0 ms | 25.7 ms
LevelDB (Java) | 0.9 ms | 1.0 ms
LevelDB (JNI) | 0.9 ms | 0.9 ms
======================================
(Note: the different de-queuing times for KahaDB between openwire and AMQP
is most likely due to caching with the ActiveMQ client.)
As you can see, performance with KahaDB is about 2x on AMQP compared to
openwire. However, it is more than 25x with LevelDB using AMQP!!
So here are my questions: why is the performance between openwire and AMQP
so much different? Is this a fluke or a bug in one of the libraries or did I
miss something in my tests?
There is also a lesson learned for me: performance between LeveDB Java and
native (JNI) seems almost identical and hence it may not worth the hassle to
deal with the native LevelDB.
some other broker.
This message is rather long but has some surprising and also unexpected
results, so please bear with me and read on...
I have used the following setup:
Broker:
* Virtual Machine with CentOS 6.0 64bit
* 2 virtual CPUs and 6GB RAM
* latest Oracle JVM (1.7.0_45)
* ActiveMQ 5.9.0 (built from source)
* Openwire and AMQP connectors are both configure using NIO
Client:
* Client running on separate VM connected via corporate Gigabit LAN to
broker VM
* Client using the "standard" ActiveMQ JMS client in one test and the
Qpid-amqp-1-0-client-jms library for another test (the qpid-amqp library was
built from source using the latest head with a recent patch)
* The ActiveMQ JMS client was connecting with caching and pre-fetch enabled.
This feature does not exist with the AMQP client library.
The test consists of a very simple scenario:
1. En-queue 1000 messages (1024 bytes message body) in a single threaded
application using a single connection and session
2. After completing step #1, de-queue those 1000 messages in the same single
threaded application using the same connection but with a new session
I measured the time it took to en-queue and de-queue each message using
System.nanoTime() with a resolution of +/- 100 nanoseconds. I essentially
took the time before I called producer.send(msg) and then took the time
immediately after the call returned.
The same measurement was applied with the de-queue - I took the time before
a consumer.receive(timeout) and immediately after.
I configured and measured my ActiveMQ 5.9.0 broker with three different
persistent stores:
1. KahaDB (the default)
2. LevelDB (Java)
3. LevelDB (native via JNI)
I installed the native LevelDB 1.7 Rel2 from the standard CentOS repo.
Since I am particularly interested in performance of persistent messages, I
will only present those results here:
Here are the results using the "native" ActiveMQ client via openwire.
======================================
Persistent Store | en-queue | de-queue
KahaDB | 57.9 ms | 0.3 ms
LevelDB (Java) | 28.6 ms | 0.2 ms
LevelDB (JNI) | 26.3 ms | 0.2 ms
======================================
It is visible that LevelDB seems about 2x faster than KahaDB.
And now comes the surprise, at least to me. Here are the results connecting
with the qpid-amqp-1-0-client-jms library.
======================================
Persistent Store | en-queue | de-queue
KahaDB | 24.0 ms | 25.7 ms
LevelDB (Java) | 0.9 ms | 1.0 ms
LevelDB (JNI) | 0.9 ms | 0.9 ms
======================================
(Note: the different de-queuing times for KahaDB between openwire and AMQP
is most likely due to caching with the ActiveMQ client.)
As you can see, performance with KahaDB is about 2x on AMQP compared to
openwire. However, it is more than 25x with LevelDB using AMQP!!
So here are my questions: why is the performance between openwire and AMQP
so much different? Is this a fluke or a bug in one of the libraries or did I
miss something in my tests?
There is also a lesson learned for me: performance between LeveDB Java and
native (JNI) seems almost identical and hence it may not worth the hassle to
deal with the native LevelDB.