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

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 991 - refreshlinks.php slow in CVS 1.4
refreshlinks.php slow in CVS 1.4
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
General/Unknown (Other open bugs)
1.4.x
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: ---


Attachments

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 
manipulated.

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.


Navigation
Links