Endre, Any idea if this applies to Artemis as well? Cheers, Martin. -----Original Message----- From: Endre Stølsvik <en...@stolsvik.com> Sent: Saturday, January 29, 2022 6:20 AM To: dev@activemq.apache.org Subject: Re: Interesting/surprising performance wrt. NON_PERSISTENT messaging
Further interesting finding: Only the jmsProducer.setDeliveryMode(..) have any effect on the timing: If employing the jmsMessage.setJMSDeliveryMode(..) method to get semantically exactly the same messages sent with same DeliveryMode (that is, PERSISTENT vs. NON_PERSISTENT), you lose out on those blazing fast "non-Transactional, non-Persistent" timings. Each test is time for sending and in case of 'Transactional', committing, [1000] messages no store, non-Transactional, non-Persistent: [32.237903] ms <- This is no longer superfast no store, non-Transactional, Persistent: [27.756596] ms no store, Transactional, non-Persistent: [37.082023] ms no store, Transactional, Persistent: [35.110782] ms ALWAYS, non-Transactional, non-Persistent: [4108.457421] ms <- ... and neither this ALWAYS, non-Transactional, Persistent: [4102.393857] ms ALWAYS, Transactional, non-Persistent: [3954.603762] ms ALWAYS, Transactional, Persistent: [3978.435732] ms PERIODIC, non-Transactional, non-Persistent: [58.224914] ms <- .. nor this PERIODIC, non-Transactional, Persistent: [81.982655] ms PERIODIC, Transactional, non-Persistent: [67.837032] ms PERIODIC, Transactional, Persistent: [58.78441] ms On Sat, Jan 29, 2022 at 4:26 AM Endre Stølsvik <en...@stolsvik.com> wrote: > Hi! > > I observed a performance/timing situation that I found a bit > surprising, and made a little test for it. You may find that here: > https://github.com/stolsvik/activemq_perf_issue > > When running ActiveMQ with default config, it uses KahaDB as backend > with JournalDiskSyncStrategy.ALWAYS which flushes to disk after every > operation. This is to live up to the JMS promises of persistent > messaging where operations should actually have been stored to disk when e.g. > producer.send() or session.commit() returns. > > This constant flushing gives a very heavy performance impact, and one > should really consider the pros and cons of using PERIODIC instead. > > However, I was a bit surprised by an observation: If you run the JMS > Session in Transactional mode, but also do > producer.setDeliveryMode(DeliveryMode.NON_PERSISTENT), one might > believe that there wouldn't be a need to flush the disk, as one has > specifically told the system that "this doesn't really matter". > However, the performance impact from "Transactional, non-Persistent" > is just as heavy as with > non-Transactional+Persistent and Transactional+Persistent. > > With non-Transactional + non-Persistent, even with > JournalDiskSyncStrategy.ALWAYS, the speed is blazing. > > One might argue, well don't use Transactional then. But Transactional > also brings another feature, whereby you may receive a message, and > send a message, and have these two operations inside a transactional boundary. > This aspect of Transactional is valuable even if though the messages > are non-Persistent. And the broker evidently handles this logic > already even without persistence, since if you say > BrokerService.setPersistent(false) > and thus turn off the entire storage of the broker, it still handles > this aspect of Transactional messaging. > > It would have been valuable to be able to "selectively" turn off this > pretty massive hit of flushing to disk if the messages inside the > Transaction was non-Persistent. > > Note: The Java class in this repo uses an in-vm broker, with the "vm://" > connection. However, this situation was first observed with a remote > broker, so the effects of interest are the same over TCP or over VM. > > Each test is time for sending and in case of 'Transactional', > committing, [1000] messages > > no store, non-Transactional, non-Persistent: [4.26321216] ms > no store, non-Transactional, Persistent: [26.784713] ms > no store, Transactional, non-Persistent: [32.404009] ms > no store, Transactional, Persistent: [46.314925] ms > ALWAYS, non-Transactional, non-Persistent: [3.9833712400000003] ms > ALWAYS, non-Transactional, Persistent: [4235.887625] ms > ALWAYS, Transactional, non-Persistent: [4040.549101] ms <-- This one is > unfortunate! > ALWAYS, Transactional, Persistent: [3902.525469] ms > PERIODIC, non-Transactional, non-Persistent: [3.85038125] ms > PERIODIC, non-Transactional, Persistent: [78.012904] ms > PERIODIC, Transactional, non-Persistent: [39.030052] ms > PERIODIC, Transactional, Persistent: [94.339609] ms > > >
