Special:Statistics unacceptably slow (on first load)
Closed, ResolvedPublic
Actions

Assigned To

None

Authored By

	Nikerabbit
	Sep 13 2009, 7:47 AM

Description

Takes about 30 seconds in the first load. 30 seconds is near our deployment limit (currently increased to 45s), and over the development limit (20s) we use at translatewiki.net.

Subsequent views take a few seconds. The only slow part in it is the query for active users:
1252827223.73: SQL: SELECT /* SiteStatsUpdate::cacheUpdate Nike */ COUNT( DISTINCT rc_user_text ) FROM bw_recentchanges WHERE (rc_user != 0) AND rc_bot = '0' AND (rc_log_type != 'newusers' OR rc_log_type IS NULL) LIMIT 1
1252827226.36: SQL: UPDATE /* SiteStatsUpdate::cacheUpdate Nike */ bw_site_stats SET ss_active_users = '1671' WHERE ss_row_id = '1'

Why is it cached, but still counted and re-cached on every view? Also note that we do keep quite a long history for recent changes.

Version: 1.16.x
Severity: normal

Details

Reference: bz20622

Event Timeline

• bzimport raised the priority of this task from to Medium.Nov 21 2014, 10:49 PM

• bzimport added a project: MediaWiki-Special-pages.

• bzimport set Reference to bz20622.

• bzimport added a subscriber: Unknown Object (MLST).

Nikerabbit created this task.Sep 13 2009, 7:47 AM

is it happening with $wgMiserMode too? :)))

(In reply to comment #1)

is it happening with $wgMiserMode too? :)))

No:

Set active user count

		if( !$wgMiserMode ) {
			$dbw = wfGetDB( DB_MASTER );
			SiteStatsUpdate::cacheUpdate( $dbw );
		}

hehehe! :)

Fixed in r56271 - should be daily now.

Special:Statistics unacceptably slow (on first load)Closed, ResolvedPublicActions

Description

Details

Event Timeline

Special:Statistics unacceptably slow (on first load)
Closed, ResolvedPublic
Actions