So it really wasn't PHP but Apache right? In an hour you could have switched out your front end server to Nginx and had it serve responses from Memcached and then keep the Apache/PHP backend and change it to update Memcached on bid changes. Here are some links: http://www.igvita.com/2008/02/11/nginx-and-memcached-a-400-b... http://lserinol.blogspot.com/2009/03/speeding-up-your-nginx-...

The more generalized takeaway from this is that you shouldn't use a heavyweight listener to handle polling (or websockets in the near future) if you can avoid it. PHP was the culprit here, but I can't help but think you'd have had the same problem if you were trying to do the same thing with RoR, any Java app server, or any of the Python frameworks. Likewise, node.js or Twisted probably would have been an equally effective replacement.

Good for you! I read all of the other guys asking, "but why didn't you do this? ..." I myself am a throwback from the C/C++ days and I frequently re-write stuff in C. That's how it's supposed to be done. Write as much as you can as fast as you can up-front, then optimize your bottlenecks using more efficient methods. I'm happy that C improved your situation that drastically. I agree that the overhead of lighttpd, then apache, then php might have been the real killer in your situation, and

So... what you built was a Facebook version of https://www.wavee.com/ (or any one of the other dozens of sites), which is basically a way of taking foolish people's money. Replacing PHP/Apache fork/threads with a C daemon is a good migration, though most any language with an async sockets library worth a damn should be able to handle thousands of simple requests every second.