Last modified: 2012-05-03 02:42: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.
First Last Prev Next    This bug is not in your last search results.
Bug 34451 - Heavy DB Usage from API call list=allusers with auactiveusers=
Heavy DB Usage from API call list=allusers with auactiveusers=
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
API (Other open bugs)
unspecified
All All
: Normal normal (vote)
: 1.19.0 release
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks: 31217
  Show dependency tree / graph
 
Reported: 2012-02-16 17:56 UTC by Mark A. Hershberger
Modified: 2012-05-03 02:42 UTC (History)
8 users (show)

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

Attachments
Add an attachment (proposed patch, testcase, etc.)

Description Mark A. Hershberger 2012-02-16 17:56:44 UTC 
It seems to me that the "activeusers" parameter in the allusers API-query [http://www.mediawiki.org/wiki/API:Allusers] is quite heavy on the database.

I tried
  http://en.wikipedia.org/w/api.php?action=query&list=allusers&augroup=ipblock-exempt&aulimit=100&auactiveusers=1
earlier today which was "Served by mw7 in 16.976 secs". It's probably in an SQL cache now because I can get the result much quicker now.
Seeing that I followed with a request that is not filtered by group, which timeouts:
  http://en.wikipedia.org/w/api.php?action=query&list=allusers&aulimit=1&auactiveusers=1

Looking at the code I see that it's implemented as a grouped JOIN of `recentchanges` and `user` with an un-indexed WHERE; I'm no MYSQL expert but that doesn't seem like a good idea on enWP.
Comment 1 Mark A. Hershberger 2012-02-16 17:57:19 UTC 
Oops, meant to say that this is a report I got in email.
Comment 2 Sam Reed (reedy) 2012-02-16 18:43:35 UTC 
Hide it behind miser mode?

But we still have http://en.wikipedia.org/wiki/Special:ActiveUsers
Comment 3 Sam Reed (reedy) 2012-02-16 20:53:28 UTC 
Aaron looked at fixing it in 1.18wmf1 in r111667

I merged to trunk in r111673

Merged to 1.19 and 1.19wmf1 in r111675
Comment 4 Amalthea 2012-02-17 00:16:25 UTC 
Live hack means it's live on enWP?
A first API call 
http://en.wikipedia.org/w/api.php?action=query&list=allusers&aulimit=500&auactiveusers=1
didn't timeout anymore, but still took 33 seconds.

http://en.wikipedia.org/w/index.php?title=Special:ActiveUsers&offset=X&limit=500
"only" took 15 seconds.
Comment 5 Sam Reed (reedy) 2012-02-17 00:20:42 UTC 
Yeah, it's all live on the cluster
Comment 6 Antoine "hashar" Musso (WMF) 2012-03-01 13:30:42 UTC 
With the above fix what prevents us from marking this bug as fixed? Is there anything else to fix?
Note You need to log in before you can comment on or make changes to this bug.
First Last Prev Next    This bug is not in your last search results.

Navigation
Links