Topic on Project:Support desk

Jump to navigation Jump to search

[REOPENED] Caching issue makes MediaWiki painfully slow

6
2A01:E35:2E04:96F0:BE5F:F4FF:FE2B:7B03 (talkcontribs)

Hi folks,

MediaWiki behaves very differently with PHP op-code caching enabled/disabled: WITH caching, page loads take roughly 10s each; WITHOUT caching, page loads take less than 1s. First off, stack info:

  • nginx 1.2.6 with PHP handled by PHP-FPM
  • MySQL 5.5.29-1
  • PHP 5.3.21-1 with XCache 3.0.1, Suhosin 0.9.33
  • MediaWiki 1.20.2 with Nuke 1.1.7, Renameuser, ParserFunctions 1.4.1, Vector 0.3.0, WikiEditor 0.3.1

So, I had a MediaWiki 1.15 setup working, and decided to upgrade to MediaWiki 1.20. After upgrading, I noticed a significant performance degradation in page load time (above 10s).
Investigation led me to try and comment out the $wgMainCacheType = CACHE_ACCEL; directive in LocalSettings.php. This seemed to solve the issue (below 1s load time).

However, this is more of a workaround than a real solution. So I'm asking for help here, to find the real cause to the problem, and a cure for it.
Here are links to profiling logs generated with and without caching:

  • WITH caching:
  • WITHOUT caching:

Looks like most of the 10s loading time is being eaten up in function MessageCache::load().
The following message seems weird to me:

  • WITH caching:
    MessageCache::load: Loading fr... cache is empty, loading from database, loading FAILED - cache is disabled
  • WITHOUT caching:
    MessageCache::load: Loading fr... got from global cache

Could it be that MessageCache::load() waits for something and times out after 10s? If so, what would it be waiting for? How do I fix it?
During installation, MediaWiki did not report any issue with my setup.

At any rate, here is the XCache part of the phpinfo() output. XCache reports to be enabled indeed: .

Can anyone suggest a course of action to further investigate this issue?
Unfortunately, the wiki is private and I cannot provide a URL for accessing it.

Thanks a bunch in advance,
Quentin

MarkAHershberger (talkcontribs)

Can you switch to APC for caching? It looks like XCache is really discouraged.

Bawolff (talkcontribs)

I think what's likely happening is that APC object cache size is too small (I think the apc.shm_size in php.ini controls that, not sure off the top of my head. xcache.var_size is equivalent setting for xcache i believe), so the i18n cache stuff can't be loaded from cache slowing things down. If APC caching is disabled, then the i18n cache gets stored in the db, which well slightly slower than APC, at least works. (setting manual:$wgCacheDirectory to something writable by the webserver might help with this situation).

If this is indeed what is happening, I think i18n cache is supposed to also go to db when using APC, which I guess is not happening, which sounds like a bug.

2A01:E35:2E04:96F0:BE5F:F4FF:FE2B:7B03 (talkcontribs)

Cache size was 32M, seemed quite decent to me. =/

Anyway, I switched to APC with 64M shm_size, and it works like a charm. 1st load for any page is roughly 500ms, subsequent loads are less than 100ms. Thank you guys very much for the suggestion. :)

Cheers, Quentin

62.231.10.170 (talkcontribs)

This was caused by mw bug (or bug in some xcache version).

xcache_get returns NULL if nothing can be acquired from cache, but mw waits for false.

if ( $this->get( $key ) === false ) {

at line 147 of includes/objectcache/BagOStuff.php, while xcache will return NULL in this case, so

for ( $i = 0; $i < MSG_WAIT_TIMEOUT && !$this->mMemc->add( $lockKey, 1, MSG_LOCK_TIMEOUT ); $i++ ) {

at line 581 of includes/cache/MessageCache.php will get timeout in 10 seconds (default value).

mediawiki 1.20.2, xcache v3.0.1

I'll report this to bugzilla if not forget.

Reply to "[REOPENED] Caching issue makes MediaWiki painfully slow"