in reply to Re^2: skipped days, skipped votes (exactly why)
in thread skipped days, skipped votes
Two problems. First, if I get promoted on a day I don't vote, I'd rather have my new number of votes when I return rather than my old. So you'd have to modify your plan some to account for that.
Second, that isn't the problem. (: The vote fairy doesn't take that long to run and it doesn't update any nodes that it doesn't have to. We go through the node cache so that updates get propogated properly to any mod_perl processes that already have your node cached in RAM. Otherwise it might make the problem worse. This means that we update a couple of records that we don't have to and we update lots of fields that we don't have to. But the problem with updating lots of fields that we don't have to is not so much the time required (at least as far as the vote fairy is concerned) but that this leads to the race condition that can overwrite our updates.
It wasn't that the vote fairy was loading down the SQL server too much. It was that the SQL server was loaded down too much for the vote fairy to even get connected to it. I assume this had something to do with a run-away backup, though that doesn't quite make sense (perhaps the backup load fooled Pair into thinking their was a problem and they restarted the DB). But the backups are not a load problem any longer (I've run them several times during busy periods, like today, now that I've made them gentle like I'd always planned to).
And I'd rather just fix the node cache to eliminate lots of related problems at the same time.
Thanks for the suggestion, though. :)