Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Moving from PHP to C saved my web startup.

news.ycombinator.com

Post reply on HN
Print view View original

51–60 of 85 posts

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

#51

Post by silentbicycle »

BuckToBid wrote: post #31
rograndom wrote: post #30

Instead of loading apache for each php call, why not have a few PHP FastCGI instances running? They're lighter weight than apache+mod_php and you don't have to wait for them to load for each call?

Mostly just because I've never used FastCGI before, and I have played around with making C/C++ servers for fun before. Seemed like the fastest solution and so far its worked out better than expected.

This is a bit of an oversimplification, but where CGI spawns a new process for each connection, FastCGI* starts the process once, then runs a loop to handle each connection, so the process startup, database connection, etc. costs amortize to essentially nothing -- many of the constant factors for working in a higher level language are eliminated.

FastCGI is worth looking into - a lot of popular webservers support it, and it's less of a complete model change than switching to an event-based system (e.g. node.js) or an MVC framework.

* Or SCGI, which is a newer, simpler design with similar goals.

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

#52

Post by DrJosiah »

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.

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

#53

Post by BuckToBid »

DrJosiah wrote: post #52

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.

Yes there are many penny auction sites out there. The whole reason to link it to facebook is so that you know its a real person you are bidding against. How do you know wavee has all real people bidding? You don't some of their users could just as easily be bots bidding items up automatically.

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

#54

Post by unshift »

can't you use a comet connection with something like orbited instead of polling? i wouldn't trust polling via HTTP GET with "real-time accurately synchronized countdown" -- a couple of small delays can skew your entire countdown, and delays are easy to come by across the internet. especially with creating multiple connections.

as much as i dislike like it, i doubt the problem has much of anything to do with php. a simple fastcgi server hooked into lighttpd would have probably had the same outcome of better performance, or even apache with mod_php.

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

#55

Post by konad »

BuckToBid wrote: post #48
konad wrote: post #39

Earlier quoted context omitted.

it's not called a forkbomb for nothing

http://en.wikipedia.org/wiki/Fork_bomb 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.

You're right about the webserver being overload. Threads would be less expensive than processes.

I would use Go for this service myself. Defending against abuse is hard whichever way one goes.

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

#56

Post by toolate »

BuckToBid wrote: post #21
rarestblog wrote: post #20

Why do you use AJAX to update countdown? Using AJAX for this would give you MUCH less accuracy than plain-old JavaScript with time delta of user time to server time: If you just need to time sync - you could receive server time once (remembering user time, when you sent request for server time), then just compensate user time with that value. In PSEUDO-JavaScript (client-side): // do this once: var user_time = (new D…

The reason it has to continually sync is that any user could place a bid at any moment. This makes the timer increase and top bidder change, so every user must be notified of the change. Its asking the server for how much time is left in each auction not what time it is in the real world. Sorry for the confusion.

Why don't you use long polling rather than sending a request a second?

You could even incorporate the timer into a single request.

    do {
        sleep(1);
        $seconds_remaining = fetch_auction_time_from_memcache();
        echo "updateActionTime($seconds_remaining);";
        flush();
    } while ($seconds_remaining > 0);

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

#58

Post by sedachv »

silentbicycle wrote: post #49
sedachv wrote: post #47

Earlier quoted context omitted.

...which [Erlang] is not compiled.

False. Erlang is compiled natively via HIPE (the "High Performance Erlang" compiler, nice acronym!) on many platforms, and compiled to BEAM bytecode on the rest. Running Erlang has some overhead, sure, but that's because it's designed for distributed systems where you can pull a plug out of the wall without interrupting service. I wouldn't use Erlang for number crunching, but using it as a glue language for a network…

I didn't know that, I thought everything ran on beam. I guess the point is the canonical Ruby implementation is really slow when it doesn't need to be. It's not like it's a hard problem, or even that it hasn't already been solved (look at GemStone's Maglev: http://ruby.gemstone.com/)

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

#59

Post by BuckToBid »

toolate wrote: post #56
BuckToBid wrote: post #21

Earlier quoted context omitted.

The reason it has to continually sync is that any user could place a bid at any moment. This makes the timer increase and top bidder change, so every user must be notified of the change. Its asking the server for how much time is left in each auction not what time it is in the real world. Sorry for the confusion.

Why don't you use long polling rather than sending a request a second? You could even incorporate the timer into a single request. do { sleep(1); $seconds_remaining = fetch_auction_time_from_memcache(); echo " updateActionTime($seconds_remaining); "; flush(); } while ($seconds_remaining > 0);

This is interesting. Would this work if I was on the site for say an hour? Or is there some limit to the amount of time you can send data like this? I have never tried anything like this. What is the overhead like?
Post reply on HN