Yes this is exactly the advantage I was thinking of. If we pursue this we'll test it and I'll report back for posterity.
On Tue, Jul 28, 2020, 1:35 PM Justin Bertram <jbert...@apache.org> wrote: > 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 > > > > > > > > > > > > > >
