When were they re-enabled for en.wiki? Have they been fixed to generate more meaningful data and minimize server load? They don't appear to tick for each page reload so something is different.
--mav
On Wed, 26 Mar 2003, Daniel Mayer wrote:
When were they re-enabled for en.wiki? Have they been fixed to generate more meaningful data and minimize server load? They don't appear to tick for each page reload so something is different.
They're not re-enabled, I just forgot to disable the counter _display_ code for en.wiki when I installed a bug fix in the skin code.
-- brion vibber (brion @ pobox.com)
On Wed, Mar 26, 2003 at 11:43:40AM -0800, Brion Vibber wrote:
On Wed, 26 Mar 2003, Daniel Mayer wrote:
When were they re-enabled for en.wiki? Have they been fixed to generate more meaningful data and minimize server load? They don't appear to tick for each page reload so something is different.
They're not re-enabled, I just forgot to disable the counter _display_ code for en.wiki when I installed a bug fix in the skin code.
Speaking of this, I don't see why they can't be reenabled. However, instead of doing it in realtime (would which kill your performance), why not do it at night? Parse through the Apache log, compile a list of how much each article counter needs to be incremented, connect to MySQL... and do it. :)
On Wed, 26 Mar 2003, Nick Reinking wrote:
Speaking of this, I don't see why they can't be reenabled. However, instead of doing it in realtime (would which kill your performance), why not do it at night? Parse through the Apache log, compile a list of how much each article counter needs to be incremented, connect to MySQL... and do it. :)
Because I don't care about the counters, and I'm still way behind schedule on things I think are important, like better caching and setting up additional languages on the new system, so I haven't gotten to it; and no one else has done it either.
Here's what a line of the wiki's logfile looks like: 20030326195656 0000.175 /wiki/Styx timestamp response time path
Parsing is left as an exercise to the reader... :)
-- brion vibber (brion @ pobox.com)
(Brion Vibber vibber@sal-sun062.usc.edu): On Wed, 26 Mar 2003, Nick Reinking wrote:
Speaking of this, I don't see why they can't be reenabled. However, instead of doing it in realtime (would which kill your performance), why not do it at night? Parse through the Apache log, compile a list of how much each article counter needs to be incremented, connect to MySQL... and do it. :)
Because I don't care about the counters, and I'm still way behind schedule on things I think are important, like better caching and setting up additional languages on the new system, so I haven't gotten to it; and no one else has done it either.
Here's what a line of the wiki's logfile looks like: 20030326195656 0000.175 /wiki/Styx timestamp response time path
Parsing is left as an exercise to the reader... :)
While we're at it, I added the wiki logfile just to get some initial stats, but do we really need it anymore? I'm sure Apache is much more efficient at it, and it would eliminate a disk access per page fetch. The test suite can be used to get timing info now.
On Wed, 26 Mar 2003, Lee Daniel Crocker wrote:
While we're at it, I added the wiki logfile just to get some initial stats, but do we really need it anymore? I'm sure Apache is much more efficient at it, and it would eliminate a disk access per page fetch. The test suite can be used to get timing info now.
It's useful for debug info, but for general... The response time does show how much time is being spent in the script as opposed to time spent sending things over the network (but it's not entirely reliable, it seems to sometimes kick off PHP output buffer while still counting). Maybe not the most useful thing.
Exercise for the reader is scrapped, you'll have to use the apache log. ;)
-- brion vibber (brion @ pobox.com)
wikitech-l@lists.wikimedia.org