Scaling a Chat App - Short Polling VS. Long Polling (Ajax, PHP)

Scaling a chat app - short polling vs. long polling (AJAX, PHP)

A few notes:

• Polling every second is overkill. The app will still feel very responsive with a few seconds of delay between checks.
• To save your db's traffic and speed responses, consider using an in memory cache to store undelivered messages. You could still persist messages to the db, the in memory cache would simply be used for queries for new messages to avoid queries to the db every x seconds by each user.
• Timeout the user's chat after x seconds of inactivity to stop polling to your server. This assures someone leaving a window open won't continue to generate traffic. Offer a simple "Still there? Continue chatting." link for sessions that timeout and warn the user before the timeout so they can extend the timeout.
• I'd suggest starting out with polling rather than comet/long polling/sockets. Polling is simple to build and support and will likely scale just fine in the short-term. If you get a lot of traffic you can throw hardware and a load balancer at the problem to scale. The entire web is based on polling - polling most certainly scales. There's a point where the complexity of alternatives like comet/long polling/etc make sense, but you need a lot of traffic before the extra development time/complexity are justified.

Questions about long polling in Ajax php Any real solution?

Edit:

Basically my answer was to switch from long polling to short polling. This was wrong of me. I am a bad answerer.

clarification lives here, along with some pros/cons and possibly a reason for your error:

Scaling a chat app - short polling vs. long polling (AJAX, PHP)

Original:

First glance: I think the issue you're running into is that you're polling every second, but telling the server to sleep for a second. if you change that if to a while then you'll be telling it to sleep indefinitely, until a change has been made to the db and the $currentmodif is updated. What you want to do is send a response back to the js, not wait for a change to be made before responding.

instead try this logic:

• send the timestamp through as you're doing, but if the database hasn't been updated, just return an empty response or a code you can recognize as "not updated" and do nothing.
• get rid of that "sleep", theres no need to wait to return a response.
• suggestion: in the javascript, use a setInterval instead of a recursive setTimeout, and keep a reference to that interval around so you can clearInterval later and stop the polling.
• I'm 99% positive that facebook and other services use websockets instead of polling (at least for any browsers that support it). you may want to investigate this.

Short-polling vs Long-polling for real time web applications?

• Short polling (a.k.a. AJAX based timer):

  Pros: simpler, not server consuming (if the time between requests is long).
  
  Cons: bad if you need to be notified WHEN the server event happens with no delay.
  Example (ItsNat based)

• Long polling (a.k.a. Comet based on XHR)

  Pros: you are notified WHEN the server event happens with no delay.
  Cons: more complex and more server resources used.
  Example (ItsNat based)

Chat application polling

Without seeing your loadNew function, an easy fix might be to change that function to return your ajax call (return $.ajax({...});) and change the code you posted to this:

pollTimeoutTime = 500;
function poll() {
    pollTimeout = setTimeout(function () {
        loadNew().done(function (result) {
            if (!new_messages_count) {
                //Increasing delay between polls as no messages are incoming to a maximum of 1 minute/60 seconds
                if (pollTimeoutTime < 60000) pollTimeoutTime = pollTimeoutTime * 1.25;
            } else {
                //Reset delay between poll to default of 0.5 seconds
                pollTimeoutTime = 500;
            }
            poll();
        });
    }, pollTimeoutTime);
}

AJAX Polling Frequency - To long poll or not to long poll?

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.

Chat application AJAX polling

You might also want to look into Comet.

It's used by GTalk, Meebo, and many other chat applications. A few years ago when I was experimenting with it, there weren't very many libraries or details about server architecture to implement it, but it looks like there is a lot more stuff out now.

Have a look at the cometd project for more technical information.

---

Related Topics