I'm not aware of any specific rule of thumb on the upper limit on the number of queues. The broker itself has no arbitrary limit so it really depends on your hardware, heap-size, use-case, performance goals, etc.
Justin On Thu, Dec 22, 2022 at 6:36 AM Mark Johnson <spike.john...@gmail.com> wrote: > Hi Justin, > > Is there a rule of thumb for the limit of Y? > > Just wondering about the realistic upper limit on the number of queues. > > Thanks > > On Wed, 21 Dec 2022 at 15:21, Justin Bertram <jbert...@apache.org> wrote: > > > Generally speaking I would avoid use-cases involving a JMS queue + > > selectors when possible for the following reasons: > > > > - The queue has to be scanned over and over for messages which match the > > selectors. The deeper the queue gets the more scanning is required. This > > adds up over time. > > - A single queue with X traffic will almost certainly not be as fast as > Y > > queues with X/Y traffic on each. Put simplistically, more concurrency > > equals more performance both in terms of throughput and scalability. > > > > > > Justin > > > > On Tue, Dec 20, 2022 at 5:26 PM John Lilley > > <john.lil...@redpointglobal.com.invalid> wrote: > > > >> Greetings! > >> > >> > >> > >> We have a design wherein every “job” that runs offers up an RPC service > >> via a unique queue name. Which means that if 100 jobs are running, > there > >> are 100 queues. I’ve read that, in theory, all jobs could share a > single > >> queue and use Message Selectors (in JMS) to receive only messages that > they > >> should service. Can anyone help me understand the tradeoffs? Would > shared > >> queue tend to use less broker memory? Would the shared queue > performance > >> start to degrade under load? > >> > >> > >> > >> Thanks, > >> > >> John > >> > >> > >> > >> [image: rg] <https://www.redpointglobal.com/> > >> > >> John Lilley > >> > >> Data Management Chief Architect, Redpoint Global Inc. > >> > >> 888 Worcester Street, Suite 200 Wellesley, MA 02482 > >> > >> *M: *+1 7209385761 <+1%207209385761> | john.lil...@redpointglobal.com > >> > >> PLEASE NOTE: This e-mail from Redpoint Global Inc. (“Redpoint”) is > >> confidential and is intended solely for the use of the individual(s) to > >> whom it is addressed. If you believe you received this e-mail in error, > >> please notify the sender immediately, delete the e-mail from your > computer > >> and do not copy, print or disclose it to anyone else. If you properly > >> received this e-mail as a customer, partner or vendor of Redpoint, you > >> should maintain its contents in confidence subject to the terms and > >> conditions of your agreement(s) with Redpoint. > >> > > >
