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

41–50 of 85 posts

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

#41

Post by bobf »

dugmartin wrote: post #9
BuckToBid wrote: post #7

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…

I couldn't agree more. Nginx and HAProxy will seem like miracle workers after seeing Apache's performance.

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

#45

Post by rubashov »

BuckToBid wrote: post #13
dugmartin wrote: post #11

Earlier quoted context omitted.

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. Good luck with your app!

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.

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.

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

#46

Post by sedachv »

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.

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

#47

Post by sedachv »

lkrubner wrote: post #38

Polling in real time always needs to be done in some compiled language. The good folks at 37 Signals ran into this when they launched their CampFire app. For instance, consider what David Heinemeier Hansson says about Campfire, the chat software he helped developed. First written in Ruby On Rails, it soon became clear that the code that polls to see who is in the chat room needed to be as fast as possible: "We rewrot…

...which [Erlang] is not compiled.

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

#48

Post by BuckToBid »

konad wrote: post #39
BuckToBid wrote: post #13

Earlier quoted context omitted.

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.

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.

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

#49

Post by silentbicycle »

sedachv wrote: post #47
lkrubner wrote: post #38

Polling in real time always needs to be done in some compiled language. The good folks at 37 Signals ran into this when they launched their CampFire app. For instance, consider what David Heinemeier Hansson says about Campfire, the chat software he helped developed. First written in Ruby On Rails, it soon became clear that the code that polls to see who is in the chat room needed to be as fast as possible: "We rewrot…

...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 networked system hits all its strong points.

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

#50

Post by kqueue »

BuckToBid wrote: post #44
kqueue wrote: post #42

have you considered using rabbitmq/0mq? It sounds like they are perfect candidates for what you are trying to achieve.

I had never heard of those before. Are they capable of working inside any web broswer? Looking it up right now.

Yes, you can reach a queue via a web browser using the proper api access you provide.

If you have 100 users, each one waiting for a message in their queue, then you can "broadcast" a single message to all of the queues (or a group) with one command. All the users waiting for a message in their queue will get a copy.

Another approach which is hack-ish imo, is to use something like jabberd to broadcast messages.

Post reply on HN