I've temporarily disabled talk page notification for IP addresses that aren't logged in, as this dumps an extra database query for every single hit.
If it doesn't make a big difference, it'll get turned back on shortly.
-- brion vibber (brion @ pobox.com)
Hi Brion Vibber,
I've temporarily disabled talk page notification for IP addresses that aren't logged in, as this dumps an extra database query for every single hit.
If it doesn't make a big difference, it'll get turned back on shortly.
It does seem to make a noticeable positive difference.
Schneelocke wrote:
Hi Brion Vibber,
I've temporarily disabled talk page notification for IP addresses that aren't logged in, as this dumps an extra database query for every single hit.
If it doesn't make a big difference, it'll get turned back on shortly.
It does seem to make a noticeable positive difference.
It's unfortunate that we have to, that's a very important feature. It would probably be wise to advertise this in Wikipedia:Announcements, otherwise the rate at which anonymous users are banned will suddenly jump.
May I suggest also reducing the number of update queries to sitestats? I was going to do it myself, but I'm not going to have time for the next week and a half. My idea was to use a shared memory location which is incremented each time a page is viewed, and then flush it to the database once every 100 views. If a type of shared memory can be found which survives an apache restart, it would be very accurate. Then we just lose 50 views once a month or so. I'm not sure how much performance would be gained, but I'm willing to bet it's worth the effort.
-- Tim Starling.
On Tue, 2003-09-23 at 17:10, Tim Starling wrote:
May I suggest also reducing the number of update queries to sitestats?
The total page view count is a pretty pointless statistic, and it also fails to count cached pages. We can get better information from the web server logs.
I'm just going to turn that off. (Left off at 63,197,425 current article page views since July 2002 -- minus any cached page views since May. Not bad!)
The _edit_ counter and _article_ counter will continue to update.
-- brion vibber (brion @ pobox.com)
Brion-
I've temporarily disabled talk page notification for IP addresses that aren't logged in, as this dumps an extra database query for every single hit.
If it doesn't make a big difference, it'll get turned back on shortly.
Hmz, how do we measure "big difference"? Wikipedia has been everything from "dog slow" to "super fast" since this announcement, but that's about the usual. I don't believe one SELECT to a small table on each pageview matters much, but then again, I still don't understand all the locking issues which we seem to have. Remember the orders-of-magnitude increase in speed after we switched the searchindex to a static copy? Yet I don't really see why it ended up being locked so much.
Presently I see locking issues and very slow rendering of long pages (IMHO still caused by the link checking process, but I haven't validated that theory) as the two main causes of our dismal performance (that, and the fact that people like us too damn much). I had hoped that Tim's links update fix would make a big difference, but it turns out that saving long pages is still slow because they are also *displayed* after saving them, and it's the displaying itself that is slow. I don't really know how much of an impact the current 2394^34 pass parser has on the performance on Larousse, but I wouldn't rule that out as a cause of headaches either.
Regards,
Erik
wikipedia-l@lists.wikimedia.org