Mailing List Archive

en.wiki page counters
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
Re: en.wiki page counters [ In reply to ]
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)
Re: en.wiki page counters [ In reply to ]
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. :)

--
Nick Reinking -- eschewing obfuscation since 1981 -- Minneapolis, MN
Re: en.wiki page counters [ In reply to ]
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)
Re: en.wiki page counters [ In reply to ]
> (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.

--
Lee Daniel Crocker <lee@piclab.com> <http://www.piclab.com/lee/>
"All inventions or works of authorship original to me, herein and past,
are placed irrevocably in the public domain, and may be used or modified
for any purpose, without permission, attribution, or notification."--LDC
Re: en.wiki page counters [ In reply to ]
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)