posts - 81, comments - 257, trackbacks - 0

Wednesday, September 12, 2012

MediaWiki IIS7 Output Caching and Friendly/Short URLs

MediaWiki has been running painfully slow for me out of the box and the solution, as it always seems to be, was to enable caching.

I first enabled caching within MediaWiki, but this only helped… a little. I did this first step within LocalSettings.php

$wgCacheDirectory = "c:\your\path\to\cache";
$wgFileCacheDirectory = "c:\your\path\to\cache ";
$wgEnableSidebarCache = true;
$wgUseFileCache = true;
$wgShowIPinHeader = false;
$wgEnableParserCache = true;
$wgCachePages = true;

$wgMainCacheType = CACHE_ACCEL;
$wgMessageCacheType = CACHE_ACCEL;
$wgParserCacheType = CACHE_ACCEL;
$wgMemCachedServers = array();

Using Chrome's Developer Tools, particularly the network tool where each request is shown, I noticed almost all of the time was spent in loading load.php! The result was correctly being cached at the application level, with 304 Not Modified responses, but it was taking a couple of seconds to return that response. With a dozen or so resources to load (CSS/JS) this accumulates to half minute load times quickly… Something internal to MediaWiki was painfully slow. But the content returned by load.php is just static resource; just cache it at the server level.

Using the IIS GUI here will lead you into a trap – or at least it lead me into one. The GUI tends to convert "*.php" into ".php" extensions, which don't match. So, using your favorite editor add a caching entry into Web.config for the MediaWiki site. Here I chose ten minute cache timeouts.

 

<caching>

<profiles>

<add extension="*.php5" policy="CacheUntilChange" kernelCachePolicy="CacheUntilChange" duration="00:10:30" varyByQueryString="*" />

<add extension="*.php" policy="CacheUntilChange" kernelCachePolicy="CacheUntilChange" duration="00:10:30" varyByQueryString="*" />

</profiles>

</caching>

And hopefully that should do it, after the first few calls to load.php the responses should be speedily cached. Note you may want to vary by header as well if you want to simply send 304 responses with no content to save bandwidth by using browser cache. My particular application is on an intranet.

 

Note on browsing speed

My installation of MediaWiki is loading about ten resources. Most browsers support 6 concurrent requests (hits to load.php), see http://www.browserscope.org/?category=network. This means that the page load would have to wait for load.php twice, rather than ten times in parallel. With Firefox and IE the number of simultaneous requests can be increased, reducing the load time further, see http://gnoted.com/3-hacks-for-firefox-double-internet-browsing-speed/.

This shaves a couple seconds off of a fresh load (where the cache is empty).

 

 

 

 

 

 

 

posted @ Wednesday, September 12, 2012 3:07 PM | Feedback (2) |

Powered by:
Powered By Subtext Powered By ASP.NET