Thursday, November 19th, 2009

NGiNX HTTP Push Module

Category: Comet

Even PHP developers can write web applications that use all sorts of fancy long-polling.

That is what Leo said about his NGiNX HTTP push module:

This module turns Nginx into an adept HTTP Push and Comet server. It takes care of all the connection juggling, and exposes a simple interface to broadcast messages to clients via plain old HTTP requests. This lets you write live-updating asynchronous web applications as easily as their old-school classic counterparts, since your code does not need to manage requests with delayed responses.

NHPM fully implements the Basic HTTP Push Relay Protocol, a no-frills publisher/subscriber protocol centered on uniquely identifiable channels. It it an order of magnitude simpler and more basic than similar protocols (such as Bayeux). However, this basic functionality together with the flexibility of the server configuration make it possible to reformulate most HTTP Push use cases in Basic HTTP Push Relay Protocol language with very little application- and client-side programming overhead.

Configure NGiNX and write some code to talk to it.

Posted by Dion Almaer at 6:15 am

3.9 rating from 33 votes


Comments feed TrackBack URI

“rhymes with Ninternet Nexplorer”
I love good comments

Comment by emehrkay — November 19, 2009

Very cool!

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?

Comment by broofa — November 19, 2009

Excellent tool for applications which rely solely on JS clients. But i suppose that when you need to interface it with a different backend (Rails/Python) it doesn’t really help you much unless you play with the code.

Comment by Nichol4s — November 19, 2009

Nginx has always been the best webserver, and now even more so.

Comment by Darkimmortal — November 19, 2009

Nginx is quite excellent at dealing with open connections. Using this module adds a small amount of overhead — a dozen or so bytes per channel, and around a hundred per each open subscriber request (depending, of course, on the size of the request).

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.

Comment by slact — November 19, 2009

Leave a comment

You must be logged in to post a comment.