You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@activemq.apache.org by bdv <ba...@gmail.com> on 2012/06/18 10:08:56 UTC
How good is ActiveMQ supposed to perform?
Recently I have been running some tests against a single instance of ActiveMQ
5.6.0.
The goal of these tests was to get to an instance that could handle a load
according to following parameters:
- message size: 2048 bytes
- transactional
- persistant
- message rate: 2500 messages/second with a possible growth of 5000 m/s
- non-bulk message transactions (needs to support 2500 clients that each
send a message, so sending as bulk is cheating)
You may have noticed 2 other possible combinations:
Both of these are not possible because working non-transacted and then
requesting SESSION_TRANSACTED is obviously silly.
Test-setup:
- 1 producer for which the session is committed after each message
- 1 consumer that simply receives the messages and keeps a count
(AtomicInteger).
- The 2500 message-objects are created beforehand so only the actual sending
/ committing is benchmarked.
- ActiveMQ config :
Hardware setup:
- a client: i7 3ghz+, 16gb ddr3, 128 gb ssd
- a server: i7 3ghz+, 16gb ddr3, 128 gb ssd
- a gigabit switch
My questions:
- Is it normal for a test with just transactions and no persistence to be
slower than a test with transactions and persistence?
- Why is there such a high impact when transactions are activated? Is there
a way to remedy this?
--
View this message in context: http://activemq.2283324.n4.nabble.com/How-good-is-ActiveMQ-supposed-to-perform-tp4653343.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Re: How good is ActiveMQ supposed to perform?
Posted by bdv <ba...@gmail.com>.
Thank you for your quick reply, I do appreciate it.
I ran the testsuite again with 4 simultaneous threads (meaning 4
connections, sessions, producers, consumers), and these were the results:
*****************
REPORT
*****************
35.985847s -> Msgcnt: 2500|Msgsize:
2048|Transacted|PERSISTENT|AUTO_ACKNOWLEDGE
35.440556s -> Msgcnt: 2500|Msgsize:
2048|Transacted|PERSISTENT|CLIENT_ACKNOWLEDGE
35.457222s -> Msgcnt: 2500|Msgsize:
2048|Transacted|PERSISTENT|DUPS_OK_ACKNOWLEDGE
35.507576s -> Msgcnt: 2500|Msgsize:
2048|Transacted|PERSISTENT|SESSION_TRANSACTED
70.415115s -> Msgcnt: 2500|Msgsize:
2048|Transacted|NON_PERSISTENT|AUTO_ACKNOWLEDGE
70.42604s -> Msgcnt: 2500|Msgsize:
2048|Transacted|NON_PERSISTENT|CLIENT_ACKNOWLEDGE
71.32817s -> Msgcnt: 2500|Msgsize:
2048|Transacted|NON_PERSISTENT|DUPS_OK_ACKNOWLEDGE
70.65203s -> Msgcnt: 2500|Msgsize:
2048|Transacted|NON_PERSISTENT|SESSION_TRANSACTED
*0.762125s *-> Msgcnt: 2500|Msgsize: 2048|Not
transacted|PERSISTENT|AUTO_ACKNOWLEDGE
*0.5094472s *-> Msgcnt: 2500|Msgsize: 2048|Not
transacted|PERSISTENT|CLIENT_ACKNOWLEDGE
*0.48527578s *-> Msgcnt: 2500|Msgsize: 2048|Not
transacted|PERSISTENT|DUPS_OK_ACKNOWLEDGE
0.0s -> Msgcnt: 2500|Msgsize: 2048|Not
transacted|PERSISTENT|SESSION_TRANSACTED
0.32700574s -> Msgcnt: 2500|Msgsize: 2048|Not
transacted|NON_PERSISTENT|AUTO_ACKNOWLEDGE
0.13212825s -> Msgcnt: 2500|Msgsize: 2048|Not
transacted|NON_PERSISTENT|CLIENT_ACKNOWLEDGE
0.124347255s -> Msgcnt: 2500|Msgsize: 2048|Not
transacted|NON_PERSISTENT|DUPS_OK_ACKNOWLEDGE
0.0s -> Msgcnt: 2500|Msgsize: 2048|Not
transacted|NON_PERSISTENT|SESSION_TRANSACTED
Like you stated, a difference would be noted in transacted mode. However,
what I didn't expect was the increase in time it suffered when just
persisting. I suppose this is the disk sync bottleneck you mentioned?
Considering we are using a SSD in this case, I didn't really expect there to
be any bottleneck?
--
View this message in context: http://activemq.2283324.n4.nabble.com/How-good-is-ActiveMQ-supposed-to-perform-tp4653343p4653346.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Re: How good is ActiveMQ supposed to perform?
Posted by Gary Tully <ga...@gmail.com>.
Sending a single message in a transaction is not efficient and not
giving you anything because a single non transacted send gives the
same guarantees (w.r.t message durability) with less protocol
messages.
For jms sends, transactions only make sense when you want to batch
messages so that you can combine multiple sends into one disk sync on
the broker.
In your scenario, using multiple producers over their own connections
will give you the best performance because you will be able to get
concurrent writes going on on the broker journal and the broker will
be able to combine more than one write into a disk sync.
For persistent messages, waiting for a disk sync before replying to a
send or commit is usually the limiting factor.
On 18 June 2012 09:08, bdv <ba...@gmail.com> wrote:
> Recently I have been running some tests against a single instance of ActiveMQ
> 5.6.0.
>
> The goal of these tests was to get to an instance that could handle a load
> according to following parameters:
>
> - message size: 2048 bytes
> - transactional
> - persistant
> - message rate: 2500 messages/second with a possible growth of 5000 m/s
> - non-bulk message transactions (needs to support 2500 clients that each
> send a message, so sending as bulk is cheating)
>
>
>
> You may have noticed 2 other possible combinations:
>
>
>
> Both of these are not possible because working non-transacted and then
> requesting SESSION_TRANSACTED is obviously silly.
>
> Test-setup:
>
> - 1 producer for which the session is committed after each message
> - 1 consumer that simply receives the messages and keeps a count
> (AtomicInteger).
> - The 2500 message-objects are created beforehand so only the actual sending
> / committing is benchmarked.
> - ActiveMQ config :
>
>
> Hardware setup:
>
> - a client: i7 3ghz+, 16gb ddr3, 128 gb ssd
> - a server: i7 3ghz+, 16gb ddr3, 128 gb ssd
> - a gigabit switch
>
> My questions:
> - Is it normal for a test with just transactions and no persistence to be
> slower than a test with transactions and persistence?
> - Why is there such a high impact when transactions are activated? Is there
> a way to remedy this?
>
> --
> View this message in context: http://activemq.2283324.n4.nabble.com/How-good-is-ActiveMQ-supposed-to-perform-tp4653343.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
--
http://fusesource.com
http://blog.garytully.com