Given it is using JMS 2 it wont yet work with the client being used here.
On Thu, 3 Feb 2022 at 09:56, Francesco Nigro <nigro....@gmail.com> wrote: > > HI Endre, > > you can try using https://github.com/apache/activemq-artemis/pull/3857 the > perf client tool to quickly check these differences too. > Giving me some feedback on the tool eheh :P > > It's based on JMS 2 asynchronous send, although not so much adopted, has > the interesting feature to allow many in-flight persistent messages to be > sent, in a non-blocking fashion, helping to get the best from the > Artemis journal (and disk) that naturally batches them on the disk. > > Il giorno gio 3 feb 2022 alle ore 10:49 Endre Stølsvik <en...@stolsvik.com> > ha scritto: > > > You are totally correct, sorry about that. I actually find the JMS API a > > tad convoluted. Since I do actually change the delivery mode per message in > > my library, I knew it was possible, and was like "ah, there it is" when I > > found that setter on the message. > > > > When changing to using 'producer.send(msg, deliveryMode, pri, ttl)', that > > "further finding" disappears! Great. > > > > The original and main point still seems to stand though. If you want me to > > send that to the user list then I'll do that. > > > > I've updated the repo. > > > > Each test is time for sending and in case of 'Transactional', committing, > > [1000] messages > > no store, non-Transactional, non-Persistent: [4.36516976] ms > > no store, non-Transactional, Persistent: [27.665534] ms > > no store, Transactional, non-Persistent: [29.056998] ms > > no store, Transactional, Persistent: [30.520276] ms > > ALWAYS, non-Transactional, non-Persistent: [4.41806886] ms <-- (This is > > great, avoiding the hit.) > > ALWAYS, non-Transactional, Persistent: [4107.414315] ms > > ALWAYS, Transactional, non-Persistent: [4118.322262] ms <-- This one > > is unfortunate! > > ALWAYS, Transactional, Persistent: [4143.173852] ms > > PERIODIC, non-Transactional, non-Persistent: [4.453423] ms > > PERIODIC, non-Transactional, Persistent: [58.694872] ms > > PERIODIC, Transactional, non-Persistent: [28.286106] ms > > PERIODIC, Transactional, Persistent: [64.690608] ms > > > > > > > > On Tue, Feb 1, 2022 at 7:22 PM Robbie Gemmell <robbie.gemm...@gmail.com> > > wrote: > > > > > You should post such things to the users list. > > > > > > Your further finding is not as interesting as it may first seem, it > > > makes an invalid assumption that you get 'semantically exactly the > > > same messages sent' by using the jmsMessage.setJMSDeliveryMode(..) > > > method, which JMS defines that you do not. This method (and several > > > others like it) is specifically not meant for application usage and > > > actually shouldnt have any influence on what happens during send. It > > > is only for use by a JMS implementation itself to stamp the actual > > > details for observation after send returns, and exist to allow for the > > > case when it is operating on message objects created by another JMS > > > implementation. Only the producer's own setting or its send method > > > override argument has influence on the deliveryMode when sending. > > > > > > > > > > > https://docs.oracle.com/javaee/7/api/javax/jms/Message.html#setJMSDeliveryMode-int- > > > > > > setJMSDeliveryMode(int deliveryMode) > > > Sets the DeliveryMode value for this message. > > > > > > This method is for use by JMS providers only to set this field when a > > > message is sent. This message cannot be used by clients to configure > > > the delivery mode of the message. This method is public to allow a JMS > > > provider to set this field when sending a message whose implementation > > > is not its own. > > > > > > > > > On Sat, 29 Jan 2022 at 14:20, Endre Stølsvik <en...@stolsvik.com> wrote: > > > > > > > > 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 > > > > > > > > > > > > > > > > > > > >
