David McNett (aka Nugget) van Distributed.net heeft een .plan update gepost over de problemen met de RC5 statsbox. Iedereen die getracht heeft om de afgelopen dagen z'n statistieken te bekijken zal gemerkt hebben dat de opperkoe op dit moment nogal kaputt is:
Note to self: SQL written while listening to Rage Against the Machine will need to be cleaned up at a later date. [break] ...en dat beschouw ik als bewijs dat Nugget een koele gozer is! RATM rulez! .
"Mooo, I won't do what you tell me" zei de Opperkoe: [/break] I've got a couple working theories on the stats slowdown, and some test code to run some benchmarks. Unfortunately I noticed that the monday- morning statsdb backup didn't happen monday as it should have, so I'm in a holding pattern as the tables bcp out to a safe place. As soon as this is wrapped up I'll get to run some time tests to see if today's changes fix the problem.
The "I searched for my stats and got nugget's" problem is fixed. Most of the php3 pages have defaults where they show id #1 or team #1 if no valid data is provided to them. I made a change to psearch.php3 last night that jumps straight to psummary.php3 if the search only yields one email address. It seems that psearch was confusing a lot of people who thought didn't realize that they could click on the email address and get to a full summary page. I screwed up when I made the change, but didn't notice when I tested it because (drum roll) I tested it with my email address. In reality, it wasn't passing the id properly to psummary, but I thought it was because the default was me. oops.
It's fixed now, and should be working just fine.
I'm pretty sure we're on the right track, that the recent slowdown in processing is triggered/exacerbated by the fact that as of last week, normal stats viewing now touches the "big" rc5_64_master table. Until we added phistory, no stats pages actually hit the main table. As explained in decibel's .plan, he disabled the phistory pages to see if that would help. As you know, it didnt', but that may very well be because we missed a spot. The "today this participant did foo% of their maximum" line also hits the rc5_64_master table, and we overlooked that. So, you guys have been hitting the rc5_64_master table this whole time, even with phistory disabled.
Assuming this is indeed the cause of the problem, I made changes to the php3 code today which may eliminate the conflict. If the changes do not help (and tonight's run also takes way too long), the next step will be to disable phistory and the "today compared to best day" psummary line during the update. (not all the time, just when the update runs).
If that doesn't help, well... we'll burn that bridge when we come to it.