Last modified: 2010-05-15 15:33:48 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T2991, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 991 - refreshlinks.php slow in CVS 1.4
refreshlinks.php slow in CVS 1.4
Product: MediaWiki
Classification: Unclassified
General/Unknown (Other open bugs)
PC Linux
: Normal normal (vote)
: ---
Assigned To: Nobody - You can work on this!
Depends on:
Blocks: 202
  Show dependency treegraph
Reported: 2004-12-03 19:58 UTC by Alwin Meschede
Modified: 2010-05-15 15:33 UTC (History)
0 users

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Description Alwin Meschede 2004-12-03 19:58:53 UTC
refreshLinks.php from MediaWiki 1.3.x used to process about 800 pages per 30
seconds on my server, but with 1.4 CVS (beta 1) it comes down to an unacceptable
rate of not even 50 pages per minute.
Comment 1 Brion Vibber 2004-12-03 20:02:34 UTC
Might be a parser cache-clearing oddity. Try setting in LocalSettings.php:
$wgEnableParserCache = false;

If that doesn't affect it, I'll do some profiling runs when I have a chance.
Comment 2 Alwin Meschede 2004-12-03 20:21:35 UTC
(In reply to comment #1)
> Might be a parser cache-clearing oddity. Try setting in LocalSettings.php:
> $wgEnableParserCache = false;

Setting $wgEnableParserCache = false didn't improve the performance.
Comment 3 Alain B 2004-12-14 16:26:55 UTC
On version 1.3.8 it is very slow also  
- 30 mins for 5000 articles on Athlon 2Ghz + 750 Mo  
- and a poor HD 20MB/s (real mesurement) 
- and no log for mysql (40% longer with __huge__ logs for refreshLinks ;) 
I checked many things, but know very little ;) 
cur is InnoDB here.  
It seems to have huge impact on some performance... i don't know ! 
The cache seems to be inefficient, eats up memory but doenst provide 
speed improvement: when i split the job, the total time is the same! 
Comment 4 Brion Vibber 2005-01-15 07:43:31 UTC
I just did a refreshLinks.php which clocked 1000 pages per minute on a 2GHz 
Athlon with 512MB memory, on a database with ~32200 pages (nostalgiawiki).

This is an order of magnitude over the reported slow speeds and within an order 
of magnitude of the reported fast speeds (considering variation from CPU,
configuration, disk speeds, size of articles, etc a more direct comparison of the 
numbers is not possible offhand).

Previous extreme slowness was likely caused by the totally broken bits causing 
bug 1132, which would have hugely inflated the number of links being 

If you can still see unreasonable slowness after updating to get the fix for 1132, 
please reopen with additional data. Resolving as fixed...

Note You need to log in before you can comment on or make changes to this bug.