You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@activemq.apache.org by Youyu Shao <yo...@crd.com> on 2018/02/21 20:39:05 UTC
Artemis(2.4.0) JMS transactional session queue send/receive
performance
Hi,
Recently we start evaluating Artemis 2.4.0 JMS queue performance. Our
business logic requires
the use of transactional session, where publisher sends one message per
commit, and
consumer receives one message per commit.
Our test environment is Windows machine with 4 cores(3.70 GHz), 8 logical
processors. We simulated 10 producers, 10 consumers and 1 queue; where each
producer produces 500 messages and each consumer receives
500 messages.
Our tests yield:
1. the average sending speed is about 50 message per second,
2. the average receiving speed is about 50 message per second.
Are these performance number expected? Is there way to improve these number
through configuration?
Attached is the java test code, borker.xml and artemis.profile.cmd
The java test only depends on artemis-jms-client-all-2.4.0.jar.
Thank you for your help
JmsQueuePerfTest.java
<http://activemq.2283324.n4.nabble.com/file/t378931/JmsQueuePerfTest.java>
broker.xml <http://activemq.2283324.n4.nabble.com/file/t378931/broker.xml>
artemis.cmd <http://activemq.2283324.n4.nabble.com/file/t378931/artemis.cmd>
--
Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html
Re: Artemis(2.4.0) JMS transactional session queue send/receive
performance
Posted by Youyu Shao <yo...@crd.com>.
Hi Mike,
Thank you very much for your input. In my case we do have SSD. After some
reading and fumbling, I am able to get the about 2000 sending/receiving
operations per second, with one message per transaction.
The specific adjustments I have done to achieve the above were:
1. using <journal-type>MAPPED</journal-type> -- instead of
<journal-type>NIO</journal-type>
2. setting <journal-datasync>false</journal-datasync> -- instead of default
true
3. setting <journal-buffer-timeout>0</journal-buffer-timeout> -- instead of
the default 7060000
With these adjustment, performance is more than adequate for our usage case.
Cheers
Youyu
--
Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html
Re: Artemis(2.4.0) JMS transactional session queue send/receive
performance
Posted by Michael André Pearce <mi...@me.com>.
Hi
That is very low tbh.
It looks like you have very slow disk io, not typical of data centre server grade modern disks. Is this an actual server? Or just your own personal desktop or something?
Im taking this from your journal buffer timeout of 7060000
Your system could perform 0.14 writes per millisecond
Just on my personal MacBook Pro 15inch (2015 model)
I get a buffer time of 64000 which allows a 15.62 writes per millisecond some 100x that of your system.
Which with transaction commit for every message and fsync enabled with NIO, will be your bottleneck. Artemis can only go as fast as physics of your kit will allow with these strict transactional and fsync settings.
I would have a couple of suggestions:
1) Go out a buy a decent Data Centre quality SSD drive.
The best disc IO we’ve seen in testing so far has been the Intel P4800X, If you have only SATA connections in your DC Server or not the cash something like an Intel S3710 or S3610, is very good. Essentially you’re looking at getting a disk with good latency and IOPs. I list Intel’s here, as its what we use in our organisation so have done a lot of testing on different disks, but Samsung etc all very similar just look at the spec sheets and obviously tests the disks.
Artemis does come with a tool in the admin to actually get the performance stats of the disk.
2) If you have to have HDD, look at a really good raid card with capacitor backed RAM or something to offload the write IO path.
3) If you can’t change the disk and think again if you really need fsync enabled?
If you’re running replicated HA then is having the data in a backup enough to cover a lights out situation for you?
If so you can decouple from you slower disk IO. If this is good enough then if you disable fsync id suggest using MAPPED and then set the buffer timeout to 0, as per the comment says in your broker.xml.
other messaging products are like this by default e.g. kafka, it doesn’t give fsync guarentees the concept is simply you have replica backups, as such artemis can do the exact same, if replicated back is enough. Obviously then perf there will be down to network links between the brokers.
4) Can you produce / consume in transactional batches e.g. 10 or more so messages (essentially on transaction commit, is when a fsync occurs)
Cheers
Mike
> On 21 Feb 2018, at 20:39, Youyu Shao <yo...@crd.com> wrote:
>
> Hi,
>
> Recently we start evaluating Artemis 2.4.0 JMS queue performance. Our
> business logic requires
> the use of transactional session, where publisher sends one message per
> commit, and
> consumer receives one message per commit.
>
> Our test environment is Windows machine with 4 cores(3.70 GHz), 8 logical
> processors. We simulated 10 producers, 10 consumers and 1 queue; where each
> producer produces 500 messages and each consumer receives
> 500 messages.
>
> Our tests yield:
>
> 1. the average sending speed is about 50 message per second,
> 2. the average receiving speed is about 50 message per second.
>
> Are these performance number expected? Is there way to improve these number
> through configuration?
>
> Attached is the java test code, borker.xml and artemis.profile.cmd
> The java test only depends on artemis-jms-client-all-2.4.0.jar.
>
> Thank you for your help
>
> JmsQueuePerfTest.java
> <http://activemq.2283324.n4.nabble.com/file/t378931/JmsQueuePerfTest.java>
> broker.xml <http://activemq.2283324.n4.nabble.com/file/t378931/broker.xml>
> artemis.cmd <http://activemq.2283324.n4.nabble.com/file/t378931/artemis.cmd>
>
>
>
> --
> Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html