5

I have a web page that I need to check the server for an update every second. Updates could be relatively frequent or infrequent. There could be a lot of web clients simultaneously checking the server for updates. This could either be an AJAX request every second, or a "long poll" which emulates server push. Which method would I want to use and why? It seems like the overhead of initiating an HTTP connection every second might make the long polling method preferable. On the other hand, there is probably a limit to the number of concurrent connections that can be maintained by the server. Some comparisons of these techniques would be useful for me to decide which way to go.

Nate Reed
  • 6,761
  • 12
  • 53
  • 67

1 Answers1

5

It depends on your webserver. There are newer webservers being developed that understand AJAX/Comet style and make long-polling very efficient. See Mongrel2 for an example.

You might also consider regular polling, but making it dynamic. Not knowing your domain, I can't make a specific recommendation. But imagine in a chat application. Instead of polling every second, I might wait a little after a chat message is sent to give the other person time. Then check a little more frequently for a while, and if I still get nothing, slow down (as the other person might be gone). I might have poll intervals from 1 second to 30 seconds depending on the situation.

It would all need to be tested for feel, but on average, I might be able to make it feel like 1 second polling, when on average it's more like 20.

Lou Franco
  • 87,846
  • 14
  • 132
  • 192
  • Interesting how chat works. My domain is auctions and I want to present bids in real time on my web page. I suppose my web page might poll more frequently as the auction nears the end since there tends to be more bids near the end. – Nate Reed Dec 06 '10 at 03:45
  • Exactly. Also, if there is autobidding, check after a bid is made until it settles down. – Lou Franco Dec 06 '10 at 13:35
  • This might not work so well since I want to display multiple auctions on the same page. There will probably always be an auction nearing its end so the polling frequency would probably always be high. – Nate Reed Dec 06 '10 at 17:18
  • Let's say I wanted to use long polling instead. I would have an endpoint that my web page queries for updates. The endpoint would query something in memory (maybe a message bus or cache) for updates and block until there is something new. Basically, I want new bids to result in updates to an in-memory collection and then waiting threads to be notified that there is something new. Does that make sense? How might I implement this - what kinds of tools would I use on the back end? Is a cache (eg. Memcache) appropriate or would I need a message bus? – Nate Reed Dec 06 '10 at 17:22
  • If there's always an auction nearing, then just use regular polling. Long polling is what you do when you want an update as soon as it's ready, but the time to the next update is potentially long. If every poll is going to result in data, and the frequency of the poll is within your tolerance for delay, just poll. – Lou Franco Dec 06 '10 at 18:22
  • Thanks for that explanation! That makes the decision more clear. – Nate Reed Dec 07 '10 at 00:48