I have run the same tests with slight variations of messages on AMD and on INTEL based systems with different clock speeds but all => 3,5GHz To be honest this used to be a much bigger issue a few years ago but with modern servers its less important (however I did make sure we for fast performance cores as opposed to huge numbers of parallel threads -> CPU are no longer the issue on these systems its not always a problem to get enough RAM :) one Ceph was running on local enterprise SSD (on bare metal worker nodes) The other on locally attached Purestorage SAN. The disks are fast but ceph is really slow. However both ActiveMQ Classic dealt with this surprisingly well. I checked with direct local disks and performance was much faster but the tradeoff for being able to run these in the kubernetes cluster and have a way to shift them around when required meant I kept it on Ceph. Please note that on Openshift Kubernetes at least we still have to manually intervene to let the stateful sets and storage work shift to new servers nicely, in case of hardware issues
Feel free to contact me directly if you have more specific questions On Wed, 19 Feb 2025 at 20:00, William Crowell <wcrow...@perforce.com.invalid> wrote: > Christian, > > Really good information. What was the clock speed on your cores? What > was your CEPH running on? SSD? > > What did you use to performance test? I found a Maven plugin and JMeter > scripts. > > Regards, > > William Crowell > > From: Christian Kurmann <c...@tere.tech> > Date: Wednesday, February 19, 2025 at 1:55 PM > To: users@activemq.apache.org <users@activemq.apache.org> > Subject: Re: Are there any hardware recommendations for ActiveMQ Classic? > [You don't often get email from c...@tere.tech. Learn why this is > important at https://aka.ms/LearnAboutSenderIdentification ] > > 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. > > > > > > > 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. > >
