Hi All, In case you’ve not seen an independent company published https://softwaremill.com/mqperf/#toc-evaluating-persistent-replicated-message-queues comparing several mainstream different brokers in the market. As you see Artemis favours very well ☺ really congrats guys!! Clebert and I worked some with a guy called Adam at the company doing the test to help fix his setup, as some basic bits out the box are were not done, also we had to work / find a better solution for improving sending/receiving client performance. First off a massive nodding of my cap to Franz who’s implementation of MAPPED journal with fsync turned off really was key to the throughput performance. I would like to discuss some bits during helping Adam I found could do with improving or at least we found it a little non-intuitive, so hopefully we can make Artemis easier for users. Async Ack on the consumer this currently in JMS api is a blocking call, to work around this we change his code to ack every 10th message, still this ack blocks, and so making the ack async in JMS would be a great win, ive already created a JIRA and started to look as some of you have noticed (as this will impact my org later down our migration also actually) Defaulting best journal type based of if you need fsync - If when creating a broker maybe an option to have fsync=false, then MAPPED becomes the default journal? There used to be just two toggles for sync, since the MAPPED work there is introduced another as such are now three toggles, is the new one really needed, as noted by Adam in his feedback, with the original two set to false, toggling the new journal-datasync made no perf difference. journal-sync-non-transactional if true wait for non transaction data to be synced to the journal before returning response to client. Default=true journal-sync-transactional if true wait for transaction data to be synchronized to the journal before returning response to client. Default=true journal-datasync It will use msync/fsync on journal operations. Default=true. Multi Master Clustering – currently the setup for clustering especially multi master with ha really isn’t very easy to understand/setup for someone new, Adam still has failed to understand what to do (and tbh when I first saw the project it took over a week or reading and re-reading the docs), compared to kafka where it just is simple and the default and really easy to start with. Could we maybe make this easier? An option I was thinking maybe where a default instance is ready for clustering setup, where each node can be a master and slave (collocated) in a default cluster/group and as nodes join they simply rebalance the slave to masters, like-wise having a notion of rack/az awareness and that a slave on the same host won’t slave for its own master, rather than having to manually create seperate groups. This would make it a lot easier to just stand up, and to expand a cluster also. Any how these 4 points really are just small, again it’s great to see such promising performance we all know Artemis can do, but to be independently benchmarked and confirmed is fantastic news. Cheers Mike
Sent from my iPhone
