Fast polling using C, memached, nginx and libevent

by amix on 3/25/2009, 9:43 AM with 18 comments
  • by axod on 3/25/2009, 3:17 PM

    >> "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).

  • by liuliu on 3/25/2009, 12:40 PM

    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.

  • by bcx on 3/25/2009, 3:13 PM

    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

  • by chiffonade on 3/25/2009, 6:27 PM

    That architecture diagram makes no sense.