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

11–20 of 85 posts

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

#11

Post by dugmartin »

BuckToBid wrote: post #10
dugmartin wrote: post #9

Earlier quoted context omitted.

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.

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!

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

#12

Post by poink »

The more generalized takeaway from this is that you shouldn't use a heavyweight listener to handle polling (or websockets in the near future) if you can avoid it.

PHP was the culprit here, but I can't help but think you'd have had the same problem if you were trying to do the same thing with RoR, any Java app server, or any of the Python frameworks.

Likewise, node.js or Twisted probably would have been an equally effective replacement.

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

#13

Post by BuckToBid »

dugmartin wrote: post #11
BuckToBid wrote: post #10

Earlier quoted context omitted.

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

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

#15

Post by BuckToBid »

jamespitts wrote: post #14

Did you create an apache module? If not, what libs did you use?

I completely bypassed apache all together. Apache is not used for the 1 second ajax call at all. The only libs i used were jansson for easy json manipulation and mysql++ for database access

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

#17

Post by BuckToBid »

AdamN wrote: post #16

Why not use a js ntp library? http://jehiah.cz/a/ntp-for-javascript Then have a dedicated ntpd daemon running. That will be way more extensible, maintainable, and scalability than a custom C program.

The timers are all set differently, we can have 9 seperate auctions going at once and all have different times they end at. Also when someone bids the timers increase. So they are not only all different but all changing constantly. Its not just a single countdown that we could sync.

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

#18

Post by rarestblog »

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

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.

Memcached? Only vertically? Horizontal scaling is built-in in all memcached clients.

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

#19

Post by BuckToBid »

rarestblog wrote: post #18
BuckToBid wrote: post #8

Earlier quoted context omitted.

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.

Memcached? Only vertically? Horizontal scaling is built-in in all memcached clients.

yes, I was just saying that we can't wait for replication, when someone places a bid all the others users must have that information immediately.

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

#20

Post by rarestblog »

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 Date()).getTime();
  ajax.call('/server-time-in-sec-since-epoch', 
    callback: 
      delta_time = recvd_server_time - user_time;
  )
  
  // then at any given second real server time is:
  var current_server_time = (new Date()).getTime() + delta_time;
  // no need for ajax calls
For more accuracy you should divide delta_time by 2 (since it's round-trip).
Post reply on HN