AJAX Polling Frequency - To long poll or not to long poll?
Asked Answered
V

2

14

I'm building a component of a web page that needs relatively constant database polling. I can see two different approaches for this, and I'm wondering if one of them is better than the others, or if I'm missing a third option.

1) Send off an AJAX request every 1 or 2 seconds to check for updates. Each request returns immediately whether or not there is new data.
2) Fire off a single AJAX request that will not return until it receives data or a timeout occurs. Upon either of those happening, it fires off the next request. (I think this is called long polling?)

The number of database queries will be the same with either, but with #2 there would be fewer requests firing from the browser which could save bandwidth and client resources. For the server, is it better to have a single PHP request that stays active and sleeps between queries, or that fires up every few seconds, polls the DB, then shuts down? Or is there no difference and I'm stressing about this too much?

EDIT: I suppose I should also state that this is a chat widget of a larger web app. A slight delay in communication is not going to kill a user, as chat is a secondary feature.

Velamen answered 1/10, 2010 at 18:30 Comment(4)
This really depends on how long the long poll will be, and the number of clients you have connecting. If you have 2 or 3, long poll may work better (since updates will be instantaneous). If you have a lot, long poll will be VERY expensive since each connection requires a PHP process (since it's PHP that's holding it open). So in that case, I'd use a "smart" polling interval. Basically, if the average time to update is 10 seconds, poll at 5, then 8, then 10, then 11, etc). Basically just cut down the time by half. It's easier on the server (since average load drops), yet is fast...Paganini
I suppose I should also state that this is a chat widget of a larger web app. A slight delay in communication is not going to kill a user, as chat is a secondary feature. But we want it to be reasonable (within 2 seconds?)Velamen
Honestly, I wouldn't do this in PHP. Get another language, and implement a queue system and use persistent TCP connections to talk back and forth... Or, why not simply install Jabber and be done (and maybe implement a JS interface to the server)...Paganini
Unfortunately, I have no control over the infrastructure... it's PHP or nothing. Also, there are limitations on things like Jabber because of the environment it's going to be installed in. Great suggestions though.Velamen
A
8

Long polling will scale better (i.e. less server load) than polling, while giving much better response times.

If your recipient polls, the average journey time of a message will be half your poll interval.

With long polling, its instant - the server only waits if there is nothing to say.

If you are doing chat messaging, go long poll; its a usability thing.

The down-side with long polling is it is more complicated to implement; but its not that much more complicated, and it is widely implemented. So if you can't use an off-the-shelf framework for your webserver of choice, you can set about writing one reasonably and you will get it working.

Asben answered 1/10, 2010 at 18:58 Comment(2)
Agreed. But with a dozen clients all hitting the system, that's a dozen php processes that are active 100% of the time. As far as scalability is concerned, I guess that's not much worse than half as many hitting it every second.Velamen
Make sure those processes are sleeping nicely, not in some polling of their own, and it'll all be nice and smooth. Worry when you have a few hundred or perhaps more clients.Asben
A
2

You can also look at websockets, part of the newest browsers (or emulated via a Flash file you drop on your page)

Asben answered 1/10, 2010 at 18:34 Comment(2)
Unfortunately, I need to be able to support current and possibly legacy browsers. Definitely worth some more research though. Thanks!Velamen
That's what the flash adapter doesAsben

© 2022 - 2024 — McMap. All rights reserved.