Page MenuHomePhabricator

Heavy DB Usage from API call list=allusers with auactiveusers=
Closed, ResolvedPublic

Description

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.


Version: unspecified
Severity: normal

Details

Reference
bz34451

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 22 2014, 12:18 AM
bzimport set Reference to bz34451.
bzimport added a subscriber: Unknown Object (MLST).

Oops, meant to say that this is a report I got in email.

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

Amalthea.wikimedia wrote:

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.

Yeah, it's all live on the cluster

With the above fix what prevents us from marking this bug as fixed? Is there anything else to fix?