Hi Alex, I'm not one of the maintainers and maybe they will respond.
To clarify, are you asking whether routing high volumes of messages though a large number of addresses is likely to lead to poor performance versus using a small number of addresses? I can't answer that but Artemis was designed from scratch for very high throughput applications with flexible routing. To reduce overheads in general consider settings that will enable automatic housekeeping - set message TTL to a low value, and consider auto creating and deleting of addresses which is the default. Dave On Sat, Jul 25, 2020, 7:21 PM Alec Henninger, <alechennin...@gmail.com> wrote: > 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 > >
