Last modified: 2014-08-08 11:20:38 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T71222, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 69222 - list=logevents slow for users with last log action long time ago
list=logevents slow for users with last log action long time ago
Status: NEW
Product: MediaWiki
Classification: Unclassified
API (Other open bugs)
1.24rc
All All
: Normal normal (vote)
: ---
Assigned To: Sean Pringle
https://de.wikipedia.org/w/api.php?ac...
: performance
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2014-08-07 10:23 UTC by Michael M.
Modified: 2014-08-08 11:20 UTC (History)
5 users (show)

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


Attachments

Description Michael M. 2014-08-07 10:23:25 UTC
Loading https://de.wikipedia.org/w/api.php?action=query&list=logevents&lelimit=1&leprop=timestamp&leuser=Gardini&format=jsonfm takes for me 114 seconds (try to append some bogus parameter if you hit the cache), and I have similar results for other users which are inactive for a long time. OTOH https://de.wikipedia.org/wiki/Spezial:Logbuch/Gardini is fast, though it provides even more information.
Comment 1 Brad Jorsch 2014-08-07 12:35:10 UTC
Sean, this seems to be a database issue. The database query here is:

 SELECT log_id,log_type,log_action,log_timestamp,log_deleted  FROM `logging` LEFT JOIN `user` ON ((user_id=log_user)) LEFT JOIN `page` ON ((log_namespace=page_namespace) AND (log_title=page_title))  WHERE (log_type != 'suppress') AND log_user = '103726' AND ((log_deleted & 12) != 12)  ORDER BY log_timestamp DESC,log_id DESC LIMIT 2

This seems to run fine on db1026, db1021, and db1045; EXPLAIN says it's using the user_time index, which makes sense. On db1005, db1037, and db1049, EXPLAIN says it uses the times index and executes slowly.

db1005
stdClass Object
(
    [id] => 1
    [select_type] => SIMPLE
    [table] => logging
    [type] => index
    [possible_keys] => type_time,user_time,log_user_type_time
    [key] => times
    [key_len] => 16
    [ref] => 
    [rows] => 6716
    [Extra] => Using where
)
db1026
stdClass Object
(
    [id] => 1
    [select_type] => SIMPLE
    [table] => logging
    [type] => ref
    [possible_keys] => type_time,user_time,log_user_type_time
    [key] => user_time
    [key_len] => 4
    [ref] => const
    [rows] => 21108
    [Extra] => Using where
)
db1021
stdClass Object
(
    [id] => 1
    [select_type] => SIMPLE
    [table] => logging
    [type] => ref
    [possible_keys] => type_time,user_time,log_user_type_time
    [key] => user_time
    [key_len] => 4
    [ref] => const
    [rows] => 21108
    [Extra] => Using where
)
db1037
stdClass Object
(
    [id] => 1
    [select_type] => SIMPLE
    [table] => logging
    [type] => index
    [possible_keys] => type_time,user_time,log_user_type_time
    [key] => times
    [key_len] => 16
    [ref] => 
    [rows] => 6194
    [Extra] => Using where
)
db1045
stdClass Object
(
    [id] => 1
    [select_type] => SIMPLE
    [table] => logging
    [type] => ref
    [possible_keys] => type_time,user_time,log_user_type_time
    [key] => user_time
    [key_len] => 4
    [ref] => const
    [rows] => 21108
    [Extra] => Using where
)
db1049
stdClass Object
(
    [id] => 1
    [select_type] => SIMPLE
    [table] => logging
    [type] => index
    [possible_keys] => type_time,user_time,log_user_type_time
    [key] => times
    [key_len] => 16
    [ref] => 
    [rows] => 6497
    [Extra] => Using where
)

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


Navigation
Links