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 <youyus...@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
