Stats Stuck

[Beyond]

It appears that the Prime Grid stats are stuck on "stats updating".

[Bok]

Thanks. I've reset that along with a few others that were stuck too .

Of course, these

are available and have the added bonus of showing individual project scores too if you hover over the names when in users...

[vaughan]

Hi Bok,
eOn stats seem stuck on the old stats system.

Request:
On the stats3 system could you add the ability to re-order the stats based on Today and also Last Update fields please (as per the current stats site).

Thanks in advance.

[Bok]

I think the eon stats are fine. They look like they've just updated..

As for the ordering, well, it's not that easy..it's one of the big problems on the old site as they are non-indexed queries, so mysql gets hammered. I could add a whole boat load of indexes to get around it, but performance whilst gathering the stats would suffer.

The 'today' ones aren't too bad as I'm already creating a temp table with the top 1000 users/teams and can display that, but lastupdate would be a horrific column to index. Perhaps I can create a temp table for this as well. Can't imagine anyone would want to see more than the top 1000 or so anyway..

Bok

[AMDave]

...As for the ordering, well, it's not that easy..it's one of the big problems on the old site as they are non-indexed queries, so mysql gets hammered. I could add a whole boat load of indexes to get around it, but performance whilst gathering the stats would suffer....

copy the front end table to make a background table which has no index
begin stats gather on copy
finish stats gather on copy
rebuild index on copy
replace "read" table with copy (which has an index) by dropping the read version and renaming the background copy to the table name of the foreground copy.

Should make it look like magic.
Takes more db space due to the table copy but keeps an indexed table at the front end and allows the grunt to be done in the background.

Is that workable?

[Bok]

Well, yeah, I already do that (to some degree).. but it would still require more multiple indexes to be rebuilt. In the case of 'today' though, that's not even actually a column but the difference between yesterdays score and the total score, so though I could use a view or update the whole table to generate the today score into a highly fluid indexed field, it's much more efficient to create a seperate table of just the top x users.

I've got some backend changes I'm going to try today which might increase the speed 5 or 10 fold anyway. If they work I would not mind having the indexes on at all.

Bok