On Thu, Jun 26, 2008 at 4:51 PM, Travis (wikiHow) <travis(a)wikihow.com> wrote:
> It's almost certainly a bogus statistic. It
could just reflect a long
> time waiting for a lock or something.
Well, I should clarify that spending a long time waiting for a lock
doesn't mean there's no problem, it just means that the problem isn't
with the particular query. Switching to InnoDB might help with that a
lot, if it is a locking issue, since reads don't normally do any
locking.
Cool. Would this be the same issue likely if I'm
occasionally seeing
LoadBalancer::getConnection take over 4 seconds in total on 1 page view?
I can't claim to have a very good idea of what that method does, in
practice. It looks quite complicated.
For replaceLinkHolders function, should $res and
$varRes eventually be
passed to a freeResult call? They don't seem to be, not sure if this is
intentional, and it seems to be the same way in 1.9.
Tim Starling has pointed out on this list that it makes no difference.
Contrary to the manual, you don't seem to need to manually free
results, at least not for memory-usage purposes. This code uses
steadily more memory until it OOMs:
$enormous = array();
while( true ) {
$enormous []= $dbr->select( 'user', '*', array( 'user_id'
=> 1 ) );
}
But this uses practically no memory:
while( true ) {
$result = $dbr->select( 'user', '*', array( 'user_id' =>
1 ) );
}
It's mostly our skin calling getParentCategoryTree
on wgTitle, one call to
set the breadcrumbs at the top of the page, another to set any meta tags
associated with the category, another to determine the top level category
for some UI features. Depending on the category structure, iterating over
the tree can make as many as 10 calls to the DB, so we'll likely start
caching that somewhere. I guess the Monobook skin doesn't show the category
tree or breadcrumbs, so this isn't as much of an issue for a typical
install.
You might want to cache it in your skin, then. Although if it's just
$wgTitle, then per-object Title-level caching should be equally
effective and not an overly large memory hog.