I was using addresses and queues interchangeably. It's been a minute since I looked at the artemis address module and I realize now they shouldn't be mixed up. I think the question is about both, since there would be many addresses–let's assume all multicast–and then each may get many consumers, creating queues.
On Sat, Jul 25, 2020 at 2:11 PM Alec Henninger <alechennin...@gmail.com> wrote: > Hello, > > I'm wondering about the overhead of queues (addresses) in Artemis. > > Thinking about ordering messages, we can use groups. But queues (with a > single consumer) are already ordered. Could we instead use many individual > queues? > > Message groups are (at least given the documentation example) suitable for > high cardinality values–things like order IDs, etc. But would Artemis cope > well with an address per some similar-cardinality attribute? (Say, many > 100s of thousands or millions of different values) > > So there are a couple of ways to ask what I'm getting at. One is, what is > the overhead of addresses in Artemis? > > I suppose another way of asking the question is, assuming the same rate of > messages and number of consumers, how many addresses could we distribute > those messages among within a single broker? What sorts of factors > (CPU/memory/disk/message rate/...) does this depend on? If the overhead of > addresses was "zero" then it wouldn't matter, but I assume that's not the > case. > > For sake of limiting the scope/giving a sense of scale, let's assume the > use case is a single producer with many (1 to ~dozens) possible consumers. > Let's also assume 10s or 100s of messages per second. > > Thanks for your time! > > Alec > > -- > Alec > (570) 856-2428 > -- Alec (570) 856-2428
