@Michael Pearce: The native module on Artemis is totally rewritten... hornetq libaio used a lot of malloc. Artemis is only calling malloc once and reusing them on a pool... a lot less locking happening... just the libaio is better..
For instance.. an issue that you had with 512 bytes blocks recently.. it wouldn't even be possible to be fixed with hornetq. I don't have number with specj.. but I remember one microbenchmark I had got 30% better with Artemis after the native update.. just by itself... ActiveMQ Artemis is getting further and further away from hornetq. it's evolving nicely IMO. On Mon, Jun 5, 2017 at 12:19 PM, Michael André Pearce <michael.andre.pea...@me.com> wrote: > @Justin > > As you noted, with all the changes since hornetq became artemis, is there an > updated run of that same JMSspec but on 2.x artemis? > > It be great if there was. Just to see. > > Sent from my iPhone > >> On 5 Jun 2017, at 16:53, Justin Bertram <jbert...@apache.org> wrote: >> >> Couple of things... >> >> 1) I agree 100% that comparing Kafka to message brokers like ActiveMQ is >> like comparing apples to oranges. They are really quite different. >> 2) My point wasn't necessarily to compare Artemis' performance with Kafka. >> My reply was simply in response to your assertion that, "Any standalone >> broker like ActiveMQ, Artemis, etc is going to be measured at a rate of >> thousands per second." I tried to make that clear by quoting this specific >> statement, but perhaps my intent wasn't as clear as I'd hoped. >> 3) I wasn't attempting to mislead anyone. I apologize if it came across >> that way. >> 4) The chance of hitting 8 million messages per second is greater than zero >> - at least as it's measured by SpecJMS. The benchmark results proves this. >> Of course, as with all things performance related the devil is in the >> details. Perhaps SpecJMS is measuring throughput in a different way than >> you might in your own test. In any event, "the most important requirement >> for the SPECjms2007 benchmark is that it is based on a representative >> workload scenario including a representative set of interactions, message >> types, message sizes and message delivery modes." [1] >> 5) Certainly fully synchronous and persistent use-cases will reduce >> performance, but many use-cases don't require that. >> 6) Clebert's "benchmark" (both code and operating environment) is quite >> different from the SpecJMS results I linked. >> >> >> Justin >> >> [1] https://www.spec.org/jms2007/docs/DesignDocument.html#S1 >> >> ----- Original Message ----- >> From: "Christopher Shannon" <christopher.l.shan...@gmail.com> >> To: users@activemq.apache.org >> Sent: Monday, June 5, 2017 8:28:50 AM >> Subject: Re: why AvtiveMq is slowly than Kafka? >> >> That may be what the benchmark says but there is zero chance of hitting 8 >> million messages per second, especially persistent messages. Take a look >> at Clebert's blog: >> http://clebertsuconic.blogspot.com/2016/12/50k-persistent-messages-per-second-on.html >> And that required making the producer completely async. >> >> Even non-persistent messages, I think under most use cases and hardware I >> would be amazed if the performance was able to go past 100k messages a >> second. >> >> This is not to bash Artemis...it is very fast for a message broker but it >> is completely misleading to try and compare real world performance of a >> standalone broker (Artemis, ActiveMQ, EMS, etc) with something like Kafka. >> >> >> >> On Mon, Jun 5, 2017 at 9:03 AM, Justin Bertram <jbert...@apache.org> wrote: >> >>>> Any standalone broker like ActiveMQ, Artemis, etc is going to be >>> measured at a rate of thousands per second. >>> >>> For what it's worth, HornetQ (upon which Artemis is based) achieved over 8 >>> million messages per second on SpecJMS [1]. I would expect Artemis' >>> performance to be comparable (or better given some enhancements put in >>> place since then). >>> >>> >>> Justin >>> >>> [1] http://hornetq.blogspot.com/2011/07/82-million-messages- >>> second-with-specjms.html >>> >>> ----- Original Message ----- >>> From: "Christopher Shannon" <christopher.l.shan...@gmail.com> >>> To: users@activemq.apache.org >>> Sent: Monday, June 5, 2017 6:45:26 AM >>> Subject: Re: why AvtiveMq is slowly than Kafka? >>> >>> You can't compare Kafka to a JMS type message broker. Kafka is completely >>> different. >>> >>> Kafka is a system that scales horizontally and is essentially a big >>> write-ahead log and breaks up the topics into partitions across many >>> servers so they can be scanned concurrently. This allows insane message >>> rates but the trade off is that the feature set is much less...there are no >>> features like message acknowledgement (messages are not deleted, they are >>> aged off and a client can seek to any point in the log), message >>> expiration, scheduled messages, transactions (although transaction support >>> is currently being worked on) etc which offloads a lot of work that a >>> typical message broker has to do. Kafka clusters can scale to thousands >>> of nodes and handle millions of messages per second. >>> >>> Any standalone broker like ActiveMQ, Artemis, etc is going to be measured >>> at a rate of thousands per second. >>> >>> On Sat, Jun 3, 2017 at 3:13 PM, Clebert Suconic <clebert.suco...@gmail.com >>>> >>> wrote: >>> >>>> For the use case you're after. (No hard syncs). Mmap is a good candidate. >>>> Probably better. >>>> >>>> >>>> Libaio was engineered the case where you hard sync with callbacks from >>> the >>>> Linux os >>>>> On Sat, Jun 3, 2017 at 12:46 PM wangqinghuan <1095193...@qq.com> wrote: >>>>> >>>>> hi clebertsuconic: >>>>> i read the blog >>>>> https://activemq.apache.org/artemis/docs/2.1.0/persistence.html >>>>> By default Apache ActiveMQ Artemis will try and use an AIO journal.But >>> it >>>>> seems like that Mmap is also a good implemention.which one gives more >>>>> performance? >>>>> >>>>> >>>>> >>>>> -- >>>>> View this message in context: >>>>> http://activemq.2283324.n4.nabble.com/why-AvtiveMq-is- >>> slowly-than-Kafka- >>>> tp4726911p4726992.html >>>>> Sent from the ActiveMQ - User mailing list archive at Nabble.com. >>>>> >>>> -- >>>> Clebert Suconic >>>> >>> -- Clebert Suconic
