Let's say I have 100,000 stock tickers (or whatever) I want to track,
each with a separate client.
There seem to be two approaches -- putting them all in one topic and
having each of the clients use a selector (ticker equivalent in a
header property), or putting messages for each header on it's own
topic and subscribing each consumer to one dedicated topic.
When I try this, the performance stinks. With the selector approach
it takes as long as like 10 minutes for 100,000 clients to connect
(using the VM transport), I need more than 256 MB of heap (512 was
fine but 384 might have been OK), and the message send/receive time
seems to go up more or less linearly with the number of clients (like,
.5 seconds for 1000 clients, 5s for 10,000 clients, 75s for 100,000
clients, all for 1000 messages). My actual selector used two header
properties, but you get the idea.
With the topic approach, which I assumed would perform better on
account of eliminating the selectors, the persistent store blew out
file handles and crashed, so I disabled persistence for the test. (Is
there a disk-based store that doesn't keep an open file for each
topic?). With that out of the way, it seemed OK up to 10,000 clients
(and up to 3x as fast for message send/receive), but isn't really able
to connect 100,000 clients each to a different topic. Like, the first
40K took 20 minutes, and the it pretty much hit the limit of 512 heap
and the next 2K took 15 minutes of which at least 12 was in GC, etc.
I'm not sure how high I'm willing to push the heap, but over 1 GB
seems out of line when I haven't sent any messages yet.
Anyway, this wasn't really what I had hoped for. Is there some good
way to customize the configuration to either handle ~100K selectors
really optimally, or ~100K topics really optimally?
Or would it just be better to have one topic where every client gets
every message and manually discards the ones it doesn't care about? I
haven't tried that yet.
Thanks,
Aaron
