Long polling PHP returns 2 results instead of one

You set a timeout like:

setTimeout()

but you are using

clearInterval()

to clear it, use clearTimeout() instead.

I know this does not answer your question exactly, but what you're doing is not gonna work anyway - long polling with PHP will crash your server when there'll be at least some more users. You use sleep, so PHP process is "hanging". PHP worker count (both for Apache, nginx or any server with PHP) is limited. As soon as you'll reach that count, new connections will be rejected. PHP is intended to give responses quickly.

For this type of solution I would suggest to use some intermediate software that's designed for it. For example, take a look at Socket.IO.

It's written in Javascript and is for both client side (JS library) and server side (Node.js). Your Node.js server can take events as they happen from PHP using REST API, queues (like ZeroMQ, RabbitMQ etc) or any other transport, like socket.IO client itself. This way you don't poll your database in PHP, you just pass that new post was added to the Node.js server, which passes this information to your client-side JS code.

$pdo->prepare('INSERT INTO ..')->execute();$dispatcher->dispatch('new_post', new PostEvent(array('id' => 123, 'text' => 'Post text')));

Long-polling is only one of supported Socket.IO protocols, and is by far not the most efficient one.

If you want to avoid Node.js, you can try ReactPHP with Ratchet, using WebSockets on client side. This works as single php process (ran from command line), thus not apache-way.

Frankly I don't see why you botyher with this kind of optimization, unless you plan to handle thousands of messages. You could as well fetch the whole lot each time the page gets refreshed.

Hammering the server with a request from each client every second will generate a huge lot of traffic anyway, so optimizations should start with defining a more reasonable polling period or a smarter, adaptative refresh mechanism, IMHO.

Now if you really want to go for it, you will have to do a proper synchronization. If you mess up the timestamps, you can skip a message that was added by someone else just as another client triggered an auto-refresh, or get the said message twice.

All your timeout handling is simply unnecessary. A server request through Ajax will produce an error event if something goes wrong, which will mean either the connection or your server went down or your PHP-side code threw some tantrum and needs a fix.

For an idea of the application structure:

• an update request will pass a timestamp to PHP, asking to retrieve all posts newer than the said timestamp. The initial value will be 1/1/1970 or whatever, so that the initial fetch retrieves all existing posts. A new timestamp will be included in the response, so that incremental requests will skip already fetched data.
• Javascript will generate such requests periodically (I would rather set the period to 30 seconds or so, to avoid excessive server load - assuming your average user can handle the frustration of waiting that long for the next batch of pseudo-tweets)
• submitting a new post will simply add it to the DB, but since all is done server-side, you won't need to bother with race conditions.

All your "time_wasted" and "cur_time" code should go to the bin.The only time reference needed is the date of the last read request from this particular client.
All you need server-side (in your "stream" PHP file) is a DB request to fetch posts newer than the client-provided timestamp, that will return a (possibly empty) list of posts and the updated value of the same timestamp.

Frankly, instead of these potentially confusing timestamps, you could as well use the unique identifier of the last post fetched (using 0 or any conventional value for the initial request).