Today I logged in to the Stack Exchange chat room for the first time. And, the first thing I want to know is how it works.

To my surprise, Firebug told me that the chat room page sends a request to the server at 1 second intervals. This is simple polling. I'm wondering why Stack Exchange do it in this way. There has been mature Comet technology (Long Poll and HTTP streaming) there and it is more efficient.

So, why did the Stack Exchange developers choose this most resource-costing approach?

  • 4
    Isn't Comet + lots of users pretty much Death To IIS? Or has that situation improved since last I looked into it...?
    – Shog9
    Mar 1, 2011 at 2:16
  • 1
    (Ah, apparently it has, or at least can be)
    – Shog9
    Mar 1, 2011 at 2:43
  • IIS can do Comet. At least Microsoft Exchange is doming Comet with IIS + ASP.NET. Mar 1, 2011 at 3:37
  • 5
    Seems to work pretty well right? If it ain't broke, don't fix it, etc?
    – TM.
    Mar 1, 2011 at 6:50

3 Answers 3


The answer is simple: Because it works.

In the very beginning of the project "chat" we decided to start out with polling, because that's the easiest thing to implement. But we would do it in a way that allows for changing the transport from polling to long polling without too much hassle, should that need ever arise.

Well, guess what: That need hasn't arisen so far. So, as TM comments: Why fix it if it ain't broke?

On a side note: "1 second interval" isn't true (but other people have made up even lower numbers), and the mythical word "efficient" means nothing if you don't qualify it.

  • 1
    Can I ask how many poll requests received per server in one second? Mar 1, 2011 at 11:52
  • @Morgan don't quote me on exact numbers, but I think the ball park is somewhere between 30 and 60 requests per second. That's distributed over two servers, but one of them could (and sometimes does, e.g. when we take one out for maintenance) handle that alone.
    – balpha StaffMod
    Apr 9, 2011 at 6:24

Chat is currently using web-sockets, with a fallback to polling if this isn't available (or dies). Do we need to? No, not really; frankly the polling has worked just fine, and hasn't given us any headaches. However, it is an obvious test-bed for playing with any web-sockets features we might want to use on the rest of the network, and was fairly easy to swap in since we intentionally left the delivery mechanism pretty vague in the system. Not having to pay the http tax each time is nice, but this wasn't actively hurting us.


Polling is a lot cheaper than most people think provided the system being probed can say "no changes" very quickly and at low cost.

Remember that to keep a TCP socket open (for Comet, etc.) needs the OS to send TCP probing packets to confirm the other end is still there, etc., so Comet does not give you a free lunch.

  • 2
    Good point (and indeed, "no changes" is very cheap in this case).
    – balpha StaffMod
    Mar 1, 2011 at 10:56

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .