6 ms·

Fast polling using C, memached, nginx and libevent

71 points by amix 18y ago

liuliu 18y ago
If it is a poll server, why not write a lite script of lua inside nginx or just a plugin of nginx? That would take full features of nginx and I guess the result would be better.
- staunch 18y ago
  I think modifying the nginx memcached module would have been ideal. Running a new server that does almost nothing does not seem like a great way to go.
- davidw 18y ago
  It'd also be interesting to see the whole thing done in Erlang, just for fun.
  - davidw 18y ago
    ... or apparently not, for those with little intellectual curiosity about a task quite well suited to Erlang.
bcx 18y ago
What is the advantage of polling over comet? I guess the real question is how often is a user re-polling the same value, without it changing. -Ben
- lhorie 18y ago
  Polling works out of the box with pretty much all web servers - the downside is that it's significantly slower and more resource intensive than comet.
  - simplegeek 18y ago
    >> the downside is that it's significantly slower and more resource intensive than comet. Any data or story to back that argument? Just curious.
    - lhorie 18y ago
      I don't have data available right now, but I have done quite a bit of research on server push technologies for one of my projects. It just comes down to bandwidth: regular polling consumes bandwidth (and the related client and server resources) even when there's no actual data being sent.
axod 18y ago
>> "From what I have seen, all comet solutions are very hacky, quirky and very hard to scale. The scaling is especially hard since the whole web-platform is built around the request-response model." I disagree about this. There's nothing hacky/quirky about comet, and it can scale really well. Some numbers from a Mibbit backend: Peak connected users: 4,000 Peak HTTP Req/s: 1,500 HTTP requests per day: 44 million Packets sent per day: 42 million Packets recv per day: 51 million (On a single 1.4GB VPS). Using *OMG* java! If you're not using comet, that HTTP req figure would be way higher, as a far larger number of HTTP requests would be unuseful (no data available). Wasting time, bandwidth, etc As well as obviously adding latency. With comet, the data is available in most instances as soon as the server has it ready. With standard polling, the user has to wait for the next poll. Comet is pretty easy to scale once you understand exactly what is going on, and how best to organize things. Mibbit uses a keep-alive long polling XHR setup which works really well. The keep-alive ensures that most of the time, you just have a tcp/ip connection open from server to client, with some HTTP request/response spam every so often, and the actual packets. Having said that, I wouldn't use any of the open source comet things I've seen out there. (I do plan to open source Mibbit at some point, which might be useful for people).
- lhorie 18y ago
  Out of curiosity, what transport are you using? Long polling or long-lived iframes? I find that the former doesn't give me low enough latency for my purposes and the latter tends to get quirky for me when I have a high spiked data throughput.
  - axod 18y ago
    long polling XHR. Latency is extremely good if the server software is up to the task. As soon as the server sends an HTTP header and data response, it's there on the XHR response. (Also iframes mean memory leak, and possibly 'loading' spinner. Neither of which you get with XHR). You can also do some neat optimizations like decide that a latency of 100ms is ok enough, and so delay sending any data for up to 100ms to see if you can piggy back on the next recv request and reduce the HTTP request count by 1. Also in order to batch up sends. For example: Without optimization-- 0ms Long polling Recv 800ms Send some data 900ms Long polling Recv (After some data was received) With optimization-- 0ms Long polling Recv (Send queued for up to 100ms) 900ms Data sent, in Long polling Recv request.
chiffonade 18y ago
That architecture diagram makes no sense.

71 points by amix 18y ago

If it is a poll server, why not write a lite script of lua inside nginx or just a plugin of nginx? That would take full features of nginx and I guess the result would be better.

staunch 18y ago
I think modifying the nginx memcached module would have been ideal. Running a new server that does almost nothing does not seem like a great way to go.
davidw 18y ago
It'd also be interesting to see the whole thing done in Erlang, just for fun.
- davidw 18y ago
  ... or apparently not, for those with little intellectual curiosity about a task quite well suited to Erlang.

bcx 18y ago

What is the advantage of polling over comet? I guess the real question is how often is a user re-polling the same value, without it changing. -Ben

lhorie 18y ago
Polling works out of the box with pretty much all web servers - the downside is that it's significantly slower and more resource intensive than comet.
- simplegeek 18y ago
  >> the downside is that it's significantly slower and more resource intensive than comet. Any data or story to back that argument? Just curious.
  - lhorie 18y ago
    I don't have data available right now, but I have done quite a bit of research on server push technologies for one of my projects. It just comes down to bandwidth: regular polling consumes bandwidth (and the related client and server resources) even when there's no actual data being sent.

axod 18y ago

>> "From what I have seen, all comet solutions are very hacky, quirky and very hard to scale. The scaling is especially hard since the whole web-platform is built around the request-response model." I disagree about this. There's nothing hacky/quirky about comet, and it can scale really well. Some numbers from a Mibbit backend: Peak connected users: 4,000 Peak HTTP Req/s: 1,500 HTTP requests per day: 44 million Packets sent per day: 42 million Packets recv per day: 51 million (On a single 1.4GB VPS). Using *OMG* java! If you're not using comet, that HTTP req figure would be way higher, as a far larger number of HTTP requests would be unuseful (no data available). Wasting time, bandwidth, etc As well as obviously adding latency. With comet, the data is available in most instances as soon as the server has it ready. With standard polling, the user has to wait for the next poll. Comet is pretty easy to scale once you understand exactly what is going on, and how best to organize things. Mibbit uses a keep-alive long polling XHR setup which works really well. The keep-alive ensures that most of the time, you just have a tcp/ip connection open from server to client, with some HTTP request/response spam every so often, and the actual packets. Having said that, I wouldn't use any of the open source comet things I've seen out there. (I do plan to open source Mibbit at some point, which might be useful for people).

lhorie 18y ago
Out of curiosity, what transport are you using? Long polling or long-lived iframes? I find that the former doesn't give me low enough latency for my purposes and the latter tends to get quirky for me when I have a high spiked data throughput.
- axod 18y ago
  long polling XHR. Latency is extremely good if the server software is up to the task. As soon as the server sends an HTTP header and data response, it's there on the XHR response. (Also iframes mean memory leak, and possibly 'loading' spinner. Neither of which you get with XHR). You can also do some neat optimizations like decide that a latency of 100ms is ok enough, and so delay sending any data for up to 100ms to see if you can piggy back on the next recv request and reduce the HTTP request count by 1. Also in order to batch up sends. For example: Without optimization-- 0ms Long polling Recv 800ms Send some data 900ms Long polling Recv (After some data was received) With optimization-- 0ms Long polling Recv (Send queued for up to 100ms) 900ms Data sent, in Long polling Recv request.

chiffonade 18y ago

That architecture diagram makes no sense.