There is certainly a practical limit, but I doubt anybody has a clear view of what it is. I think you're more likely to hit pain points with management (e.g. the web console) before the queues themselves cause problems.
Justin On Fri, Nov 4, 2022 at 2:16 PM John Lilley <john.lil...@redpointglobal.com.invalid> wrote: > Greetings, > > > We create a queue per “job” and there can be a lot of jobs. We tend to > keep them around for a while (like an hour) to service job status after the > job is complete, but this can result in a lot of mostly-idle queues. Is > there a practical limit at which Artemis becomes unhappy (low memory, > sluggish performance)? I’m sure it depends on VM sizing, but let’s just > say that we have Artemis running in a K8S pod with 4GB memory available and > 4vcpus. > > > > I’m only looking for an order-of-magnitude ballpark. Something like “no > more than N per GB memory” would be great. > > > > 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. >
