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

21–30 of 85 posts

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

#21

Post by BuckToBid »

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.

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

#22

Post by rarestblog »

BuckToBid wrote: post #19
rarestblog wrote: post #18

Earlier quoted context omitted.

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.

memcached doesn't do replication as far as I know. It will just have to do some requests second time. It still beats re-calculation on each request.

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

#23

Post by rarestblog »

poink wrote: post #12

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

I'd probably go with node.js for this task - more manageable. Twisted has a huge learning curve.

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

#24

Post by rarestblog »

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.

Personally I'd go with simple Python WSGI app or node.js app. Actually even PHP can handle 150 reqs/sec (your load at 150 users with 1 req/s) if used as nginx+php-fpm+eaccelerator. By my measures it can actually do about 1000 reqs/sec.

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

#25

Post by BuckToBid »

rarestblog wrote: post #24
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.

Personally I'd go with simple Python WSGI app or node.js app. Actually even PHP can handle 150 reqs/sec (your load at 150 users with 1 req/s) if used as nginx+php-fpm+eaccelerator. By my measures it can actually do about 1000 reqs/sec.

Yes, it would handle it and we could have kept scaling the server up to handle more and more of it. With the C app all those problems went away. It has almost no footprint and uses almost no processor power.

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

#26

Post by ary »

rarestblog wrote: post #22
BuckToBid wrote: post #19

Earlier quoted context omitted.

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.

memcached doesn't do replication as far as I know. It will just have to do some requests second time. It still beats re-calculation on each request.

Replication is the wrong word for it. Key distribution is what you want. If a given memcache server goes down then the keys it was storing should get reloaded to a different one in your pool by your cold cache loading code.

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

#28

Post by chrisaycock »

BuckToBid wrote: post #5
earlyriser wrote: post #2

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

You could store the static (non-changing) text in a couple of C strings and then call writev() to communicate everything. That would save you the step of continuously reconstructing the header.
Post reply on HN