Live data from Hacker News

Moving from PHP to C saved my web startup.

news.ycombinator.com

1–10 of 85 posts

Moving from PHP to C saved my web startup.

#1
A few months ago I took the journey into startup land. I quit my job and decided to finish the project I had been thinking about finishing for a long time. A penny auction app where users are linked to facebook identities.

One major worry right from the start with this project was that it required a real time accurately synchronized countdown across multiple browsers. I was using ajax to call back to the server for an update every 1 second to accomplish this. I knew it was going to get interesting if a lot of users joined up because they would all be calling the server once every second.

Initially I thought we would run into trouble with bandwidth, but I was wrong. After 4 days we had about 150 users up and bidding when the server decided to crash (right in the middle of an ipad auction just because my luck is that good). Being on slicehost they had us upgraded within 20 minutes, but still we were working the server hard. The timer was skipping, we were getting all kinds of strange errors in the logs and things were looking pretty bad. It wasn't bandwidth, but memory and processor usage that were the problem.

I knew from reading articles on HN regularly that PHP is terrible, but I build the app in PHP anyways along with the 1 second callback. It was the fastest way to get things up and running for me.

That night I had an idea, if I built the 1 second call back portion of the app in C the server wouldn't have to load apache with all its extensions every 1 second. So I built a very simple fork server to send updates back for the real time update.

Result: Processor 99% idle even during heavy use and memory usage basically stays exactly the same whether or not more people are watching the auctions.

We now have a few thousand users and things have not changed at all, still running great. Of course this system will have its limits but so far we have not even dented it.

If you want to see it in action you can go to http://apps.facebook.com/bucktobid

Edit: For those who want a little more detail I have a lighttpd server listening on port 80 that redirects to apache for php calls. If the call comes in for .btb (a made up extension) lighttpd redirects to the C app which listens on another port locally and serves the needed info to the browser. The updater is 100% C/C++ not an apache module.

Re: Moving from PHP to C saved my web startup.

#5

could you give more info about how you did it? I need to implement something like this for a frequent Ajax refresh.

You could google how to do a simple fork server in c/c++ and after you have that working you just need to do something like this:

stringstream response; response

  int n = write(s, response.str().c_str(), response.str().length());
  if(n 
to write back a valid header that a browser will understand

Re: Moving from PHP to C saved my web startup.

#6
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-...

Re: Moving from PHP to C saved my web startup.

#7

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-...

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.

Re: Moving from PHP to C saved my web startup.

#8

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-...

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.

Re: Moving from PHP to C saved my web startup.

#9

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-...

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.

Re: Moving from PHP to C saved my web startup.

#10

Earlier quoted context omitted.

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 thro…

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.
Post reply on HN