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.
So instead of understanding the problem and implementing the simplest possible solution, you're recommending throwing more middleware caching crap at it? Brilliant engineering. I think I understand "web scale" now.
On the frontend I was already using lighttpd, but I could have used memcached on the backend that was going to be the next step if the c app didn't work. It just worked so well I didn't have to worry about it.
I didn't mean to poop on your parade. I love writing servers too but if you have a public facing HTTP server there are a ton of obscure edge cases to worry, like some script kiddy DOSing your server by either opening a connection and keeping it open without sending anything or dribbling out a character a minute to circumvent your SIGALRM handler.
I'd think about switching back to a public interface that has been through these battles before. You could always keep your server up and use Nginx or HAProxy to front it for you and just pass the requests on.
Yeah I have run into some of those problems already. Thanks for pointing that out. You definately need a SIGALRM handler if you are thinking of doing something like this. But I don't really see how switching to Memcached is going to prevent a DOS attack. Not trying to be defensive, just really wondering if there is something I'm not getting about that.
I'm not trying to be offensive either :) I was just warning that putting up a public facing server is eventually going to make you a target. Using a battle tested server will let you concentrate on getting more people to use your app instead of fighting bored 13 year olds trying to bring your server down.
Thanks! I understand your point, but a fork server is so simple I don't think there is much that can go wrong there, if it was serving more data I would be worried, but its meant to do a quick and short reply.
Fork Bombs are easier to pull off from the command line. Not so much with DOS. I would say that loading a large webserver for each request would use up more resources than a tiny C program. Thats the whole point of the post.
Writing your own server in C seems a little crazy anymore. Just use a C++ framework like POCO or ASIO. POCO gives you a fast httpserver component with all the tricky stuff figured out.
Also because of the need for consistency and latency I'm not sure memcached would be a benefit because it could never be scaled anything but vertically anyways.
Replication is the wrong word for it. Key distribution is what you want. If a given memcache server goes down then the keys it was storing should get reloaded to a different one in your pool by your cold cache loading code.
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-...