tags:

views:

49

answers:

2

Background: 2 minutes before every hour, the server stops access to the site returning a busy screen while it processes data received in the previous hour. This can last less than two minutes, in which case it sleeps until the two minutes is up. If it lasts longer than two minutes it runs as long as it needs to then returns. The block is contained in a its own table with one field and one value in that field.

Currently the user is only informed of the block when (s)he tries to perform an action (click a link, send a form etc). I was planning to update the code to bring down a lightbox and the blocking message via BlockUI jquery plugin automatically.

There are basically 2 methods I can see to achieve my aim:

  1. Polling every N seconds (via PeriodicalUpdater or similar)

  2. Long polling (Comet)

You can reduce server load for 1 by checking the local time and when it gets close to the actual time start the polling loop. This can be more accurate by sending the local time to the server returning the difference mod 60. Still has 100+ people querying the server which causes an additional hit on the db.

Option 2 is the more attractive choice. This removes the repeated hit on the webserver, but doesn't allieve the repeated check on the db. However 2 is not the choice for apache 2.0 runners like us, and even though we own our server, none of us are web admins and don't want to break it - people pay real money to play so if it isn't broke don't fix it (hence why were are running PHP4/MySQL3 still).

Because of the problems with option 2 we are back with option 1 - sub-optimal.

So my question is really two-fold:

  1. Are there any other possibilities I've missed?

  2. Is long polling really such a problem at this size? I understand it doesn't scale, but I am more concerned at what level does it starve Apache of threads. Also are there any options you can adjust in Apache so it scales slightly further?

+2  A: 

Can you just send to the page how many time is left before the server starts processing data received in the previous hour. Lets say that when sending the HTML you record that after 1 min the server will start processing. And create a JS that will trigger after that 1 min and will show the lightbox.

Yasen Zhelev
+1, beat me to it
steven_desu
Say there was a particularly busy period on the server and latency causes the time to be out by a few seconds. The user then will be able to send information to the server that won't be processed. The same problem that option 1 suffers from.
graham.reeds
If you calulate time at the end of the script and send it almost last this will not happend.
Yasen Zhelev
A: 

The alternative I see is to get it done faster, so there is less downtime from the users perspective. To do that I would use a distributed system to do the actual data processing behind the hourly update, such as Hadoop. Then use whichever method is most appropriate for that short downtime to update the page.

spowers
Even if you speed up the process by a factor of 10, you still get 12 seconds of downtime, which might or might not be too much. You still need a solution to handle it, so back to the original question ...
Guillaume
While some time can be squeezed out of the processing time, the majority of it can only be sped up by bigger/faster hardware.
graham.reeds
Guillaume, you are correct in that, however if the time decreases then the first option is less of a problem. As far as the majority of increased speed only coming from faster hardware I guess that depends on how well your problem could be broken into independent tasks.
spowers
The majority of the processing time comes from a fairly ludicrous combat system. I've looked at it a couple of times and nothing short of a rewrite would get more than a couple of percent speedup and a rewrite could introduce subtle bugs.
graham.reeds