Channel messages are stored either in memory or, when they exceed some reasonable size threshold, in temporary files. If you intend to have millions of channels open with millions of messages that take weeks to expire and be purged, consider increasing the push_max_reserved_memory setting. CPU usage should be completely unnoticeable. Channels are stored in a red-black tree, and have an O(log(N)) retrieval cost. All other NHPM operations are constant-time, so things should scale quite well.

As for running multiple instances of this thing, the only way to do that right now would indeed be to publish all messages to all instances, probably via some very basic server-side scripting. Shared memcached storage and a facility to keep multiple instances synced up is in the works.

Relaying messages introduces virtually no overhead if your application uses a keep-alive connection to talk to the server (as opposed to, say, performing standalone curl calls every time it wishes to send a message). Otherwise, you get a TCP/IP handshake overhead per each publisher request.

I’m quite interested to know what impact this has on scalability and architecture in cases where nginx is used as a load balancer however (which, from what I can tell, is the role it is most often used for).

For example, what’s a reasonable upper limit to the number of simultaneous subscriber connections? What about subscriber message throughput (messages/sec)? I know there are all sorts of factors that contribute to what an actual production system can do, but is there any test data the author or others can share?

If handling push message traffic is the performance bottleneck for nginx compared to whatever load balancing it might be tasked for – which seems pretty likely (right?) – how does one address that? Spin up new nginx instances? That seems problematic, as you now have to ensure that messages are published to all instances. Is there a facility for this?

Also, if messages need to be processed on the back-end (e.g. to do spam filtering in the demo chat client), does the need to use HTTP to relay each message to/from the server adversely affect performance?