[Foundation-l] Why hasn't the LocalisationUpdate extension been enabled?

Tim Starling tstarling at wikimedia.org
Thu Aug 13 14:22:42 UTC 2009


Roan Kattouw wrote:
> Tim Starling <tstarling at ...> writes:
>> The LocalisationUpdate extension is slow, with a significant
>> performance loss per page view due to DB queries,
> I can't reproduce that locally. After installing LocalisationUpdate and visiting
> a few pages, I get:
> 
> LocalisationCache::isExpired(en): cache for en expired due to GlobalDependency
> LocalisationCache::recache: got localisation for en from source
> SQL: BEGIN
> DatabaseBase::query: Writes done: DELETE FROM `l10n_cache` WHERE lc_lang = 'en'
> SQL: DELETE /* LCStore_DB::startWrite Catrope */ FROM `l10n_cache` WHERE lc_lang
> = 'en'
> SQL: INSERT /* LCStore_DB::set Catrope */  INTO `l10n_cache` ...
> 
> Presumably this is LU invalidating the l10ncache. This does not happen on a
> second or subsequent page view, though. Instead, I get
> 
> MessageCache::load: Loading en... got from global cache
> 
> and I see messages being pulled from the l10n_cache table.

I don't think those queries have anything to do with LocalisationUpdate.

> If you can reproduce these extra queries locally, please tell me how.

I removed the hook LocalisationUpdate used in r52503, so it doesn't do
anything at all. You can reproduce it by reverting to MediaWiki 1.15.

I've now committed the rewrite of LocalisationUpdate I promised in the
commit message of r52503. I held off on it because I wasn't convinced
that it's a useful solution for anything.

> 
> It's true that there's a known issue with the update script being slow, but that
> shouldn't be too bad since it's only supposed to be run once every 6, 12 or 24
> hours or something.
> 
>> and it's
>> unnecessary, because the same effect can be had with a script that
>> runs svn up periodically.

I'm not talking about the update script speed, I'm talking about the
MessageNotInMwNs, which was (before r52503) called from a common case
of wfMsg() and typically did a DB query.

-- Tim Starling




More information about the foundation-l mailing list