I run approximately 15 million messages per day on 8 cores with 16GB memory using ActiveMQ classic. I unfortunately have peaks and while most messages are 1kb I have some that are >2mb.
I have done lots of performance testing to manage this and found that Artemis unfortunately was not usable for my requirements. The way it deals with constraining resources when things got close to limits meant that processing speed worsened causing more backlog and more reconnects etc. In practical terms it deadlocks with a very difficult manual path to recover without data loss. For me ActiveMQ Classic managed the same load constraints 10 - 15% faster and without crashes. For performance testing I ran approx 50million messages per day. To increase performance I run two parallel Active MQ classic. In my case the system did not scale with more CPU and Memory due to being constrained on the disk IO (running in Kubernetes with storage on slow but safe CEPH) In short. 40 million sounds like it should work fine on quite small hardware but I recommend you test and push above 40 to see if you hit limits. And check if you can logically split traffic into two instances (keeping clear of any clustering) Regards Chris On Wed, 19 Feb 2025 at 16:50, William Crowell <wcrow...@perforce.com.invalid> wrote: > Justin and Matt, > > That’s kind of what I thought. I just wanted to see if there were any > current benchmarks for Classic. I think there were at one-point years ago, > but they are so old. > > The goal right now to is produce and consume up to 40 million messages a > day. Each message would be 400-1000 bytes. I think we would need some > really beefy hardware for Classic to support this kind of traffic. Our > clients are coded against Classic library, so it would be difficult to > switch to Artemis. > > Regards, > > William Crowell > > From: Justin Bertram <jbert...@apache.org> > Date: Wednesday, February 19, 2025 at 10:37 AM > To: users@activemq.apache.org <users@activemq.apache.org> > Subject: Re: Are there any hardware recommendations for ActiveMQ Classic? > I agree with Matt 100%. > > Aside from wide variation in the workloads there is also wide variation in > performance goals. Some folks don't mind a heavy workload with relatively > high latency. Some folks want the heaviest possible workload with the > lowest possible latency. > > My recommendation would be to start by defining your workload and your > performance goals. Then start with some kind of middle-of-the-road hardware > and do performance benchmarking with your specific workload. Then adjust > accordingly. Maybe you need more CPU, more RAM, faster disk, faster > network, etc. If you can't get that then maybe you can modify your > application's behavior (e.g. batching work into transactions, using > non-durable vs. durable messages, etc.). Or maybe everything is "good > enough" and you can move on to other tasks. > > Good luck! > > > Justin > > On Wed, Feb 19, 2025 at 9:02 AM Matt Pavlovich <mattr...@gmail.com> wrote: > > > Hi William- > > > > This is a mission impossible question. The hardware required to address > > different workloads can vary wildly. For example — thousands of > > connections handling a few million messages per day vs a hundred > > connections handling 1B messages per day. > > > > ActiveMQ can be embedded down to run on a Raspberry Pi or scale up to > very > > large heaps on a single broker. > > > > That being said— the faster the disk you can get, the faster the messages > > will be processed! > > > > -Matt Pavlovich > > > > > On Feb 19, 2025, at 5:33 AM, William Crowell > > <wcrow...@perforce.com.INVALID> wrote: > > > > > > Hi, > > > > > > Are there any hardware recommendations (not minimum requirements) for > > ActiveMQ Classic? I am trying to determine what CPU, RAM, and SSD type I > > will need when sizing out a production environment. Are there any recent > > benchmark tests for a particular hardware setup? What I will probably > need > > to do is put together an environment and run JMeter tests against the > > broker to see if it meets the requirements for the number of messages > > produced/consumed that my application requires. I am assuming that the > > more producers/consumers I have then the more CPU cores I will need. > > > > > > Regards, > > > > > > William Crowell > > > > > > > > > This e-mail may contain information that is privileged or confidential. > > If you are not the intended recipient, please delete the e-mail and any > > attachments and notify us immediately. > > > > > > > > > > CAUTION: This email originated from outside of the organization. Do not > click on links or open attachments unless you recognize the sender and know > the content is safe. > > > This e-mail may contain information that is privileged or confidential. If > you are not the intended recipient, please delete the e-mail and any > attachments and notify us immediately. > >
