My advice would simply be to test your use-cases. I don't think anybody can say with confidence exactly what you're going to find. The overhead of addresses and queues certainly isn't zero.
I would add that one potential benefit of multiple addresses & queues would have over a single address/queue with message groups is concurrency. Depending on the size of the message groups, how the messages in those groups are positioned in the queue, and how many consumers there are you can hit bottlenecks due to the serialized message consumption. This is discussed a bit in the documentation [1] in the first "note" in the "Message Grouping" chapter. Justin [1] http://activemq.apache.org/components/artemis/documentation/latest/message-grouping.html On Sun, Jul 26, 2020 at 9:52 AM Alec Henninger <alechennin...@gmail.com> wrote: > Right, succinctly the scenario is: > > * Relatively low rate from message producer > * Very high possible number of addresses (though could be pruned with > TTL/auto deletion to your point; that is, only few should actually have > messages most of the time) > * Even higher number of queues (multiple consumers on each address) > > The advantage I see over message groups is small, if any, so this is mostly > an exercise in curiosity. > > On Sun, Jul 26, 2020, 6:03 AM David Martin <dav...@qoritek.com> wrote: > > > 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 > > > > > > > > >
