PHP long polling - how long should "long" be?

When using long polling in PHP, e.g.

$start_time = time();
while ((time() - $start_time) < 30) {
if ($db->getNewStuff()->rows > 0) {
    $response = "new stuff!";
    break;
}
usleep(1000000);
}
echo $response;

How do you evaluate, how "long" you "poll"? In this example, I chose 30 seconds, because... well,开发者_StackOverflow中文版 I can't even tell why.

What are the impacts when using even longer polls, several minutes or alike? Will Apache crash? Will my application get laggy / stuck / decrease performance?

Furthermore: How long should the process usleep?

Your PHP script may not live that long, depending on the time limit. So, be sure to (re)set the time limit. Otherwise I don't see any problem increasing the times.

As for how long the usleep should be, that is something that you need to benchmark for yourself. Shorter microsleeps will increase the server load, but find results faster. What is appropriate is determined very much by the rest of your application and your resources. You may even want to vary the microsleep time according to the server load (i.e. make it sleep longer when server load is high).

You can easy saturate the available apache process/workwer. For instance if the apache is configured as show below:

StartServers       2
MinSpareServers    4
MaxSpareServers    8
ServerLimit        11
MaxClients         11
MaxRequestsPerChild  4000

You can just serve 11 request ad your site will be unreachable for at last 30 seconds. If you are looking for just a proof of concept, it's ok to play with apache and PHP but on a real server you really avoid a PHP-->Apache long polling.

You need to use something likas a comet environment for a scalable solution

When usleep() is called php does nothing until the sleep expires.

Generally the default maximum script execution time is 30 seconds, but sleep() and usleep() will go on for longer because technically PHP does not have control during the sleep operation.

Have never tried any more than a few mins - and never had any issues.

Potentially if it's something busy and get lots of threads going to sleep - you could run out of threads to process other requests...

What long polling is

The code you presented isn't long polling. Long polling is when you allow clients to wait for something, and allows your user interface to respond instantly to events on the server.

The client makes a regular ajax request. Your server code might wait, or might respond immediately.

If there is nothing to return (yet), it simply makes the response take longer to respond. If and when some waited-for event occurs, it sends a response immediately.

The client polls your ajax request, which doesn't respond until some event occurs, but when that event occurs, it responds instantly. The client is expected to turn around and do another long poll request, right away.

Preventing missed events

For this reason, you usually use a sequence number in your long poll protocol. Each event is assigned a sequence number, and newer events have higher sequence numbers than older events. If you can arrange for that, then you can make the long poll be a "get events since id" request. If there are events they missed, it will return them instantly. If they gave you the latest sequence number, then there is nothing to return, so don't return any response, just make it take longer.

If multiple events sneak in between long polls, your poll will return multiple event records.

This requires some way for your code that notifies an event to notify the code that is waiting to send a response. You can implement that as a reasonable-rate poll of a key-value store, some sort of interprocess communication, or something suitably lightweight for repeated use.

Your options are somewhat limited in PHP, due to its process model. In nodejs or another single-process server architecture, you could use a simple array of responses awaiting results, and call them all, respecting each one's "since" parameter, when a new event occurs.

Classic example

A chat client is the classic example of this. All of the people on the chat page have a long poll sitting there taking long to get a response. The page working fine, just a network request taking time in the background.

When someone types a message, they post it to the server, and the handler for that inserts a message with the next id. All of the long polls will notice the new record is greater than the "since" value they are looking for, and they will immediately send a response for all records with an id greater than the "since" parameter. Essentially notifying all of the other chat participants within a short time, without making them constantly check for new messages themselves.

You should really look into using Node and Socket.io. :)

Having a total response interval of 20+ seconds will make your application prone to browser timeouts. Keep it at, or below 20 seconds -- just to be on the safe side.