Phoenix.Pubsub subscriptions performance

[chrismccord]

@blquinn

Correct me if I’m wrong: subs are stored locally only, and messages that are broadcasted via pubsub are always sent to all nodes, correct?

Correct, unless you use direct_broadcast to send to a single node, all nodes receive it.

@blquinn

If this is the case, that seems like you’d move the bottleneck (or at least more load) to the broadcast method, no?

The bottleneck on the broadcast side would be message sending, via send, which is highly optimized. I don’t have specific #'s on large hardware, but my MacBook can crank out 500,000 messages/s thru the pubsub system.

@blquinn

The bench is cool and quite promising. However, it takes place all on one node, so it doesn’t test the distribution of subscriptions.

To be clear, subscriptions in Phoenix.PubSub themselves are always local. So any load test of subscriptions will always be relevant for a single node only. The broadcast side is maybe what you meant, but I want to be clear there is no concept of a “distributed subscription” as far as Phoenix pubsub is concerned.

@blquinn

The link I supplied shows a very steep drop off of subs/sec the more nodes you add for most of the tests he did.

At a glance, the link you referenced uses pg2 for all subscriptions, making them a “distributed subscription”, but as we see, that’s not what you want in a pubsub system. A distributed load-test of Phoenix PubSub would be neat to see what kind of cluster throughput we can achieve on the broadcast side, but the subscribe side will remain the same for 1 node test or 100 node test.