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

61–70 of 85 posts

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

#61

Post by gcr »

BuckToBid wrote: post #59
toolate wrote: post #56

Earlier quoted context omitted.

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?

Not hard. The client could notice if the connection dies (JQuery has AJAX failure callbacks, for example) and then attempt to reconnect; that's the important thing.

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

#63

Post by toolate »

BuckToBid wrote: post #59
toolate wrote: post #56

Earlier quoted context omitted.

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?

I've only used it on smaller projects. Facebook use it on their frontpage for progressive loading (check the source for `big_pipe.onPageletArrive(..);`).

Longer running connections are a little more problematic, but some client side code should be able to handle the connection being closed. You just need to make sure your web server can handle the number of connections your are expecting. Apache is particularly bad for this. Something like nginx should perform better.

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

#64

Post by silentbicycle »

sedachv wrote: post #58
silentbicycle wrote: post #49

Earlier quoted context omitted.

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/ )

I've stopped commenting about MRI entirely, it just makes people mad, and it's not even fun anymore. It's too easy. Still, I have to give Matz credit for making a language a lot of people sincerely love.

I know it's splitting hairs whether bytecode + a VM counts as compiled or interpreted (it's both, really), but compiling to bytecode rather than a pure interpreter usually makes enough of a difference performance-wise that it's worth giving some credit.

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

#65

Post by mikegreenberg »

bluesmoon wrote: post #40

php isn't terrible in general, but it can be the wrong tool for certain use cases, this being one of them. In the same way, apache is also not the right tool for some use cases, this being one of them. your solution works well for you, so stick with it. if you're thinking of scaling up further, also consider an event-driven server architecture (nginx, node.js, etc).

Agreed that PHP isn't terrible. Typically, it's the programmer's fault before it's the language's. Also, I agree that PHP isn't the right solution for every problem, but if you're set on using PHP for the wrong problems and need to bitch about it, see the previous sentence.

A nice discussion on why PHP DOESN'T suck: http://stackoverflow.com/questions/309300/defend-php-convinc...

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

#66

Post by wanderr »

sedachv wrote: post #46
dugmartin wrote: post #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-...

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.

How is placing the blame on the wrong tool understanding the problem?

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

#67

Post by wanderr »

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);

I was going to suggest long polling as well. Seems to make way more sense than normal polling for this application.

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

#68

Post by DrJosiah »

BuckToBid wrote: post #53
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.

The thing is, Wavee is not an auction site. An auction site is one in which bids are free, and the winner pays what their bid says they pay. What Wavee had, and what you have built are, effectively, a method of taking money from people for the opportunity to pay money for something.

Don't get me wrong, it's an amazing racket; Wavee makes 75 cents for every bid coming in to increment the value by 1 cent. Saw a $150 iPad. That iPad has already earned Wavee's owners $11,250 without even being sold! And the use of Facebook to gain the trust of people is a good marketing tactic, but it doesn't skirt the fact that creating fake Facebook users with a bunch of friends is easy (get some pictures, feed some content in from any one of the millions of open twitter accounts, etc.), or that you have a real incentive to perpetrate fraud.

Really though, being the most honest crook among crooks still leaves you being a crook. That's why some countries have outlawed this particular kind of scam.

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

#69

Post by chc »

silentbicycle wrote: post #64
sedachv wrote: post #58

Earlier quoted context omitted.

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/ )

I've stopped commenting about MRI entirely, it just makes people mad, and it's not even fun anymore. It's too easy. Still, I have to give Matz credit for making a language a lot of people sincerely love. I know it's splitting hairs whether bytecode + a VM counts as compiled or interpreted (it's both, really), but compiling to bytecode rather than a pure interpreter usually makes enough of a difference performance-wis…

If people would just stop talking about Ruby 1.8, it wold allow for more meaningful discussion. 1.9 is a lot faster and has better support for concurrency.

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

#70

Post by Locke1689 »

silentbicycle wrote: post #64
sedachv wrote: post #58

Earlier quoted context omitted.

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/ )

I've stopped commenting about MRI entirely, it just makes people mad, and it's not even fun anymore. It's too easy. Still, I have to give Matz credit for making a language a lot of people sincerely love. I know it's splitting hairs whether bytecode + a VM counts as compiled or interpreted (it's both, really), but compiling to bytecode rather than a pure interpreter usually makes enough of a difference performance-wis…

FYI, compilers are written completely different from interpreters. Bytecode languages are compiled as well.
Post reply on HN