Last modified: 2010-05-15 14:36:18 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 3284 - Block list is very slow
Block list is very slow
Product: MediaWiki
Classification: Unclassified
Special pages (Other open bugs)
All All
: Normal minor (vote)
: ---
Assigned To: Brion Vibber
: 3314 (view as bug list)
Depends on:
  Show dependency treegraph
Reported: 2005-08-27 18:26 UTC by Robert Rohde
Modified: 2010-05-15 14:36 UTC (History)
2 users (show)

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


Description Robert Rohde 2005-08-27 18:26:37 UTC
There are presently 4744 active blocks on Wikipedia EN:

On a good day this makes the block list very slow to load.  If the servers are 
already overloaded, it is basically unusuable.

I think this is because SpecialIpblocklist::wfAddRow calls User::whoIs for each 
entry in order to identify the name of the blocking admin on each block.  That 
means that to load the block list it is presently necessary to make more than 
4744 distinct database queries.  I would suggest that either Block::enumBlocks be 
modified to join on the list of blocking admin usernames, or that the blocklist 
be reformated into pages the same way most other query pages are so it only loads 
a fraction of the blocks at any one time.

With the continuing war with the Willy on Wheels vandal (see: [[1454]]), the 
block list is only likely to grow and make the problem worse.

Comment 1 Brion Vibber 2005-08-27 20:38:34 UTC
Block::enumBlocks already does join to user to get the 
username of the blocking user; I think Tim made this change 
earlier this week.
Comment 2 Brion Vibber 2005-08-27 21:08:14 UTC
It's still hella slow though; I got times of about 11 and 
14 seconds for page rendering (and then the list has to 
download and render in the browser, which is pretty slow 
-- the uncompressed HTML comes out to 2.4 megabytes!)

This is about 2-3 milliseconds of rendering and 500 bytes 
of HTML per block.

Either paging or slimming down the output would be good, 
perhaps both. Taking bug.
Comment 3 Brion Vibber 2005-08-27 23:58:19 UTC
There's not much output to slim without removing links or data, which would make it 
harder to use.

I've added basic paging and a substring match so you can easily look for a block by 
username or IP (or subtring thereof):

Comment 4 Robert Rohde 2005-08-28 03:04:59 UTC
Thanks alot.
Comment 5 Brion Vibber 2005-08-30 22:23:44 UTC
*** Bug 3314 has been marked as a duplicate of this bug. ***
Comment 6 p_simoons 2005-09-01 07:58:46 UTC
(copied from 3314)

Ipblocklist is too long, in particular because of the excessive amount of
perma-blocked vandal accounts. If an account is permablocked for a long time, it
would be easier to unblock it and scramble the password.

Alternatively, give the Ipblocklist a pulldown menu to only show
non-permablocks, or only blocks made the last month, etc.

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