php & mysql live feed - php

Question

I'm attempting to build a live-updated system in php-mysql (and jQuery).
The question I have is if the approach i'm using is good/correct or if i should look into another way of doing it:
Using jQuery and AJAX i have made:
setInterval(function() {
Ajax('check_status.php');
},4000);
in check_status.php i use memcache, to check if the result is either 1 or 0
$memcache = new Memcache;
$memcache->connect('127.1.0.1', 11211) or die ("");
$userid.$key = md5($userid."live_feed");
$result = $memcache->get($userid.$key);
if($result==1) {
doSomething();
}
The idea is that user A does something, and that updates the memcache for user B.
The memcache is then being checked every 4 seconds via jQuery, and that way i can do a live_feed to user B.
The reason i use memcache is to limit the mysql_queries and thereby limiting the load on the datbase.
So the question is. Am i totally off here ? Is there a better way of doing this, to reduce the server load ?
Thank you

Answer 1

The server load on this is going to be rough cause every user will be hitting your web server every 4 seconds. If I were you I would look into two other options.
Option 1, and the better of the two in my opinion, is Websockets. Websockets allow for persistent communication between a server and the client. The web socket server can be created with PHP, or something else. You can then have all clients connect to the same web socket and send data to all or individual clients connected. On the client side this is done with Javascript and flash fallback for older browsers that don't support Websockets.
Option 2 is a technique called long polling. Right now your clients have to hit the web server every 4 seconds no matter what. In long polling the client sends an ajax request and you don't give back a response from the server until your memcache status changes. So basically you put the code you have now in a while loop, with a pause to prevent it from using up 100% of your server resources, and only run doSomething() if something has changed. Then on the client side when it gets a response, initiate a new ajax call that waits for a new response again. So while with what you currently have the user hits the server 15 times in one minute regardless of activity, in this method the user will only hit the server every time there is actual activity. So this normally saves you a ton of useless connections back and forth.
Look up both of these options and see which one would work better in your situation. Long polling is easier to implement but not nearly as efficient.

Answer 2

I'd rather use a version id for content. For example say the user A's content is retrieved and the version id is set as 1000. This is then saved in memcached with the key userA_1000.
If user B's action or any other action affects the user A's content, the version ID is then reset to 1001.
When you next time checks memcached, you will now check for the key userA_1001, which does not exist and will tell you that it's updated. Hence re-create the content, save in memcached and send back with the Ajax request.
User version key can also be saved in memcached in order to not to do a DB query each time.
So
User A's key/val --- user_a_key => userA_1001
User A's content --- userA_1001 => [Content]
When a change has happaned that effected the user A's content, simply change the version and update the key of the content in memcahed
User A's key/val --- user_a_key => userA_1002
So next time your Ajax request look for the users content in memcached, it will notice that there is nothing save for the key userA_1002, which will prompt it to re-create the content. If it's found simply respond saying no need to update anything.
Use a well designed class methods to handle when and how the content is updated and how the keys are invalidated.