Number of queues and topics?

[ajc1231]

What is the maximum recommended number of queues and topics for HornetQ? Is it a small number in the hundreds or could it, with appropriate hardware, be in the 10s or 100s of thousands? Is it better to have a single topic that 100,000 users subscribe to, or is it better to have 100,000 queues each with their own single-user subscriber?

[jbertram]

To my knowledge, a maximum number of destinations has not been identified, but I have every expectation that it would be arbitrary (i.e. as many as you want).

As far as having 1 topic with 100,000 subscribers vs. 100,000 queues with 1 subscriber each, it makes no difference really.  This is because every topic subscriber is represented internally as a queue so 1 topic with 100,000 subscribers would wind up being 100,000 queues internally.

[ajc1231]

That's kind of what I would have expected - since the core implementation of topic subscribers is a queue, that it wouldn't make much of a difference from that perspective. That said, the specJMS vertical vs. horizontal scenario seems to indicate that it does make some amount of a difference, with the vertical scenario having a higher number than the horizontal scenario.

One other thing that may make a difference is that the single topic would need an extra selector for discrimination on a per-user basis whereas the individual queue/user wouldn't, so while it would be a simple selector, that may make a computational difference.

Is there a difference in storage for persistent queues vs. durable subscribers? In other words, is it more efficient to store a persistent message for durable topic subscribers than it is to store a persistent message in a persistent queue for each user?

[clebert.suconic]

Is there a difference in storage for persistent queues vs. durable subscribers? In other words, is it more efficient to store a persistent message for durable topic subscribers than it is to store a persistent message in a persistent queue for each user?

I'm assuming you are talking about JMS queue here.

If you send a message to a Topic with Multiple subscriptions, you are internally sending a message to an address with multiple references.

On that case, the message is stored once on disk (and on memory), and you will have a reference record for each internal queue (or topic subscription in JMS terms).

Having multiple queues means you will have some duplication.

Regarding the question on horizontal. We need to process the routing of each queue when you're dealing with multiple queues. If you have 10K subscriptions you will have a for (i...  100000) loop doing the distribution. So, there's no free lunch here. I have measured this and I believe we are the fastest but you still need to account the processing on this.

It would be way cheaper than sending to 10K individual queues anyway.

[ajc1231]

Clebert Suconic wrote:

Is there a difference in storage for persistent queues vs. durable subscribers? In other words, is it more efficient to store a persistent message for durable topic subscribers than it is to store a persistent message in a persistent queue for each user?

I'm assuming you are talking about JMS queue here.

If you send a message to a Topic with Multiple subscriptions, you are internally sending a message to an address with multiple references.

On that case, the message is stored once on disk (and on memory), and you will have a reference record for each internal queue (or topic subscription in JMS terms).

Having multiple queues means you will have some duplication.

Regarding the question on horizontal. We need to process the routing of each queue when you're dealing with multiple queues. If you have 10K subscriptions you will have a for (i...  100000) loop doing the distribution. So, there's no free lunch here. I have measured this and I believe we are the fastest but you still need to account the processing on this.

It would be way cheaper than sending to 10K individual queues anyway.

Hi Clebert,

Thanks for the response. Yes, I'm talking about JMS queues. What I'm really trying to establish is if it would be better for me to have a queue per user (or perhaps topic, because I need to route messages for a user to different sets of listeners for a given user depending on a selector), or if I should have a topic that multiple users listen to. On the face of it, it seems a topic would be good, HOWEVER, there is a twist - I need each message to only be readable/viewable by it's intended single recipient, because it can contain sensitive data that should never be seen by other users. The security mechanism doesn't seem to let me be able to restrict this on a per-user basis when multiple users can see messages on the same topic or queue. That means that I'm faced with doing a per-user encryption on each message, which is a little expensive. I'd expect that, on average, each user would typically receive a small number of messages - the individual per-user volume would be low, but the aggregate volume could approach something like 5,000,000 messages/day on a system that will also be doing a considerable amount of other processing.

The alternative is that I have a separate queue/topic (see above comment about topic vs. queue) that is secured via the HornetQ security mechanism, and therefore don't have to encrypt the message.

What I don't know is what the more scalable solution is. In our worst case, we could have 300,000 users with each user having between 1 and 5 topic subscriptions for a total of something like 1,500,000 subscriptions. I'm planning on using both clustering and HA, in case that complicates the answer. Ideally we're going to have transient-only messages, queues and non-durable subscribers, and will generally use non-transacted sessions.

Looking at the design of HornetQ, it would appear to be a wash as to whether I use a single topic with 300,000 to 1,500,000 subscribers or 300,000 topics each with 1-5 subscribers - it looks like you do pretty much the same thing under the covers anyway. Is this a correct understanding?

[jhohenstein]

+1

I asked a similar question because I have a similar use-case.