[plans] distributed.net .plan update

plans at nodezero.distributed.net plans at nodezero.distributed.net
Tue Sep 28 21:00:01 EDT 1999

.plan updates in the last 24 hours: 
nugget :: 28-Sep-1999 20:39 (Tuesday) ::

Note to self: SQL written while listening to Rage Against the Machine will
              need to be cleaned up at a later date.

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.

To unsubscribe, send 'unsubscribe plans' to majordomo at lists.distributed.net

More information about the plans mailing list