PHP long polling, without excessive database access

Question

I've always enjoyed the idea of long polling; on my development server I've played with various notification / new post systems, each using javascript to hold a connection and 'wait' for some sort of response. I've always had an issue with many implementations of this, they all involve repetitively polling the mySQL server to check for new rows.

A dedicated server for long polling requests is a possibility, but it seems very wasteful to continuously poll (around ever 3 seconds seems common) a database server for every client. Its a huge waste of resources for something that is relatively insignificant.

Is there a batter way?

Answer 1

If your specific problem is that you're trying to avoid notifying events through a database, you should probably be looking at using shared memory or semaphores.

Instead of continuously polling the database, you would instead monitor the shared memory. When something writes to the db (I'm assuming some sort of message queue), you can flag the event via the shared memory. The listening code would detected this, and only then establish a db connection to retrieve the message. Alternatively, you could use shared memory to entirely replace the use of the database.

The reference for the php semaphore and shared memory functions is here - http://uk.php.net/manual/en/ref.sem.php

Answer 2

I would use some nosql to notify there is new data. Redis has pub/sub and a blocking list.

You can also use, for example, memcache and create a new key when the data is available.