Moving from PHP to C saved my web startup.

could you give more info about how you did it? I need to implement something like this for a frequent Ajax refresh.

  int n = write(s, response.str().c_str(), response.str().length());
  if(n < 0) error("Error writing to socket");

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

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.

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

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.

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

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

Node.js worked great for me for similar application. Built the web application in PHP and timers with Node.js

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?

Good for you! I read all of the other guys asking, "but why didn't you do this? ..." I myself am a throwback from the C/C++ days and I frequently re-write stuff in C. That's how it's supposed to be done. Write as much as you can as fast as you can up-front, then optimize your bottlenecks using more efficient methods. I'm happy that C improved your situation that drastically. I agree that the overhead of lighttpd, then apache, then php might have been the real killer in your situation, and using memcache might have helped also, but making a simple C server using fork() to handle processes and not opening it up to the world is a very good solution in my book. People think that if enough people start writing things in C, that they'll have to start doing it too - I think that's the reason for all of the backlash. Remember, there are a bunch of C and C++ programmers out there doing things that perform well and scale, but your audience on HN is mostly php/python/java programmers and web startup people who go the route of optimizing using more trendy technologies instead of down-shifting into a language like C. More power to you, fellow C programmer! :)

Not to be the unpopular one but couldn't you also have used Flash to open a socket to a server written in [name your favorite language] and had the server intermittently (every 1 second, every 500ms) send out the current tick?

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 rewrote the 100 lines of Ruby that handled the poll action in 300 lines of C. Jamis Buck did that in a couple of hours. Now each poll just does two super cheap db calls and polling is no longer a bottleneck. Campfire and a shared todo list is different because they’re not working on a shared resource. There’s no concept of locking. Or two people dragging the same item. So a 3 second delay between posting and showing up doesn’t matter. It does when you’re working on a shared resource."

http://www.ruby-forum.com/topic/62907

Later they tore out the C code and re-wrote it in Erlang.

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

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

keep-alive

it doesn't make sense to make a new connection every 1 second, esp. to apache. that is where your prob was, not php

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.

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.

Lots of really good comments here (except mine ;-)). I'm glad I read this. Is there a "Best of Hacker News" out there?

you can embed your own C code without the hassle to handle HTTP/S (or forkbombs) using KLone web server; it can easily handle thousands of requests per second.

p.s. I'm part of the company whom made it.

Couldn't it just be that you suck at writing PHP?

> I knew from reading articles on HN regularly that PHP is terrible, but I build the app in PHP anyways along with the 1 second callback

You always have to use the right tool for the job. It requires a deep understanding of what is actually going on inside the server when you write a line of code. PHP doesn't magically absolve you of that.

It really has nothing to do with PHP, C, Ruby or [insert your most reviled/loved technology here]. Calling a complex runtime for hundreds of near-contentless requests per second on a single machine is a really bad idea, no matter what environment you use.

Also, I'm sorry if I snipe from the cheap seat here, but 1 request per second per user doesn't seem like a great solution to your problem either. It might be more appropriate to just leave the HTTP connection open and push new data out through that when it becomes available, e.g. when something about the bidding process changes.

Every time I read a story like this it reminds me of a very important lesson:

The world is built from bailing wire and duct-tape. There are probably a million better, smarter, less technology illiterate ways to solve this problem, but that really doesn't matter. What matters is getting out there and doing it. Being able to do this sort of app 'correctly' would be an edge, but only to the person who can do it 'correctly', and is out there doing it.

I wish you the best of luck with your duct-tape!

So you saved this app by using fork(), not (just) by using C. You can use fork() from a lot of languages, including shell scripts and PHP.