Have you tried using your OpenWire client with Artemis? If so, what did you find?
Justin On Wed, Feb 19, 2025 at 10:05 AM William Crowell <wcrow...@perforce.com.invalid> wrote: > Justin, > > It would be OpenWire. > > Regards, > > William Crowell > > From: Justin Bertram <jbert...@apache.org> > Date: Wednesday, February 19, 2025 at 10:56 AM > To: users@activemq.apache.org <users@activemq.apache.org> > Subject: Re: Are there any hardware recommendations for ActiveMQ Classic? > Which "Classic library" are you referring to? Artemis supports the OpenWire > protocol used by the JMS client implementation shipped with Classic. > > In many cases you can simply point existing OpenWire clients from Classic > to Artemis and everything will "just work." > > > Justin > > On Wed, Feb 19, 2025 at 9:50 AM 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. > >
