Last modified: 2010-05-15 14:36:18 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: []), the
block list is only likely to grow and make the problem worse.
Block::enumBlocks already does join to user to get the
username of the blocking user; I think Tim made this change
earlier this week.
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.
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):
*** Bug 3314 has been marked as a duplicate of this bug. ***
(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.