3 ms·

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

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.

rarestblog 16y ago
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.
- BuckToBid 16y ago
  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.
toolate 16y ago
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 "<script>updateActionTime($seconds_remaining);</script>"; flush(); } while ($seconds_remaining > 0);
- BuckToBid 16y ago
  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?
  - gcr 16y ago
    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.
  - toolate 16y ago
    I've only used it on smaller projects. Facebook use it on their frontpage for progressive loading (check the source for `<script>big_pipe.onPageletArrive(..);</script>`). 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.
- wanderr 16y ago
  I was going to suggest long polling as well. Seems to make way more sense than normal polling for this application.

rarestblog 16y ago

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.

BuckToBid 16y ago
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.

toolate 16y ago

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 "<script>updateActionTime($seconds_remaining);</script>"; flush(); } while ($seconds_remaining > 0);

BuckToBid 16y ago
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?
- gcr 16y ago
  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.
- toolate 16y ago
  I've only used it on smaller projects. Facebook use it on their frontpage for progressive loading (check the source for `<script>big_pipe.onPageletArrive(..);</script>`). 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.
wanderr 16y ago
I was going to suggest long polling as well. Seems to make way more sense than normal polling for this application.