posts - 81, comments - 259, trackbacks - 0

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.




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

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



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 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

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








Print | posted on Wednesday, September 12, 2012 3:07 PM |



# ugg saappaat

Uggs boots keep feet toasty even in the freezing cold days and ugg saappaat therefore have become the ugg saappaat suomesta first choices of many customers xiaocaicl15. ugg saappaat boots This kind of footwear looks fashionable ugg saappaat oulu and unique and is available in different uggs saarbrücken styles and colors for your choices. Made with twin-faced sheepskin, these boots feel incredible ugg boots udsalg warm and comfortable. Many celebrities are ugg boots dk also spotted wearing them during the winter season ugg boots tilbud to go through the cold winter. But this conception is ugg boots online quite wrong, as wearing them sensibly especially with jeans and feathery coats really looks cool and exquisite.
11/13/2012 3:19 AM | Zkjykgsng01

# re: MediaWiki IIS7 Output Caching and Friendly/Short URLs

The web.config changes make a significant improvement in speed.
7/26/2015 5:32 PM | SChalice

Post Comment

Please add 5 and 8 and type the answer here:

Powered by:
Powered By Subtext Powered By ASP.NET