User talk:Aaron Schulz/How to make MediaWiki fast

$wgHitcounterUpdateFreq

Thanks for this page, it helped me a lot to speed up my wiki. What about adding a link to Manual:$wgHitcounterUpdateFreq as an option NOT to disable the view counter. I didn't test it 100% but $wgHitcounterUpdateFreq = '1000'; indeed reduced CPU usage on my server. --Subfader 13:23, 4 May 2010 (UTC)

$wgParserCacheType and filecache

hi,

i am using filecache. but, i see that if wgParserCacheType = cache_accel, then the APC cache is still filling up with parsed pages.

so should wgParserCacheType be set to cache_none if filecache is enabled?

Also, if Localsettings.php is changed, does the filecache automatically get invalidated? do we need to manually rebuild the filecache, or will it rebuild as the pages are accessed?

Thanks!!

If the APC cache is too small, it would be better to use memcached or at least set the parser cache type to CACHE_DB. If you mostly are getting logged-out visitors, then the filecache should work well. Changing LocalSettings does not inherently invalidate file cache. There is a $wgCacheEpoch variable though. Aaron

thanks. still unclear about: should wgParserCacheType be set to NONE if the filecache is being used? or should i disable filecache if wgParserCacheType = cache_accel or cache_db (or memcached) ?

The file cache is only used for logged-out users, so having $wgParserCacheType set to CACHE_ACCEL still helps. —Emufarmers^(T|C) 20:58, 15 September 2011 (UTC)

$wgCompressRevisions

$wgCompressRevisions is dangerous cos it can cause problems with other extensions, e.g. Extension:ReplaceText --Subfader 14:00, 14 December 2011 (UTC)

What kind of problems appeard? I just phased out ReplaceText on all of my wikis since all sorts of unreplicable behaviour occurred. Perhaps this setting might cause this. Cheers --[[kgh]] 15:00, 14 December 2011 (UTC)

Then those extensions are broken. Aaron 17:13, 16 December 2011 (UTC)

Kghbln:If you had $wgCompressRevisions = true; it's your own fault. It's a known issue (unfixable, Extension not broken).
Aaron: Yes, it can destroy pretty much. One should know what he does when using this. Worst are broken file embedding and wrongly moved file page titles. --Subfader 12:33, 18 December 2011 (UTC)

Hi Subfader, I guess this setting cannot cause problems with Extension:ReplaceText since it should not be activated anyway. Which extensions do you have in mind? As I interpret this, your warning suggests that that there are problems with core functionality, which would be bad. Cheers --[[kgh]] 23:42, 18 December 2011 (UTC)

I didn't have other extensions in mind, I just thought that if ReplaceText has problems with this setting, other extensions might have as well. It's compressing the database and cannot be undone, that's why I think the text should read a warning since it is not further explained. --Subfader 19:40, 19 December 2011 (UTC)

Fair enough. I believe that a little warning note might not hurt. Cheers --[[kgh]] 19:53, 19 December 2011 (UTC)

404 handler / $wgShowArchiveThumbnails

Set up 404 handler for $wgLocalFileRepo. If not, then at least set $wgShowArchiveThumbnails = false.

Could this be explained please?

• What's the 404 handler good for? "To display non-existing thumbs" = hotlinked images to old thumbs I meanwhile deleted?
• "$wgShowArchiveThumbnails = false" disables thumbs in the file history table. That's a very harsh change, no?

404 handling generates missing thumbnails on the fly as the browser requests them. If a user loads a page with 7 thumbnails that don't exist, the browser will request and load them in parallel (meanwhile the HTML is already loaded). Without 404 handling the generation is serialized and blocks the entire page load. Aaron (talk) 15:12, 21 May 2012 (UTC)

Thanks, makes sense. --Subfader (talk) 16:30, 10 June 2012 (UTC)

But still I think $wgShowArchiveThumbnails = false; is a too dramatic setting. It doesn't speed up the wiki in general, it removes functionality.

Well, if someone finds it fast enough, they can leave it on :) Aaron (talk) 22:00, 29 May 2013 (UTC)

I meanwhile disabled the history thumbs as well. --Subfader (talk) 13:55, 29 May 2015 (UTC)

Sequence?

Do sysadmins have to follow these steps in sequence? Or is it possible to pick and choose steps to take? Sharihareswara (WMF) (talk) 15:14, 29 May 2013 (UTC)

I personally never thought about it. No these steps do not have to be followed in a sequence. It is "just" a list of x steps. Cheers --[[kgh]] (talk) 15:33, 29 May 2013 (UTC)

Ah great and good to know.--Juandev (talk) 16:19, 29 May 2013 (UTC)

No, I think the things that depend on each other are mentioned already, so there is no exact order. Aaron (talk) 22:00, 29 May 2013 (UTC)

Realpath_cache?

I would recommend reading the following blog post. It walks you through how to examine actual realpath usage and determine the proper setting required for your wiki install. http://thehayden.org/set-monitor-phps-realpath_cache_size-correctly/ --Lotusjeff (talk) 14:00, 30 May 2013 (UTC)

$wgMessageCacheType = CACHE_MEMCACHED ?

What about adding $wgMessageCacheType to point 5? --Subfader (talk) 22:11, 29 October 2014 (UTC)

changing MediaWiki

About your recommendation "Edit the MediaWiki:Aboutsite and MediaWiki:Pagetitle system messages by changing MediaWiki into your site name. This avoids extra parsing on each hit." Where should this be done? Searching MediaWiki in the code brings it up in many places (consider i18n) so my guess is that its initialization should be overridden rather than trying to change all messages/templates that might use it.

MediaWiki:Aboutsite and MediaWiki:Pagetitle are pages on your wiki. Reach them, click "edit", change the text, click "save". --Nemo 12:25, 3 December 2014 (UTC)

There are indeed other messages using the SITENAME magic word however these are not called every time any wikipage is hit by any arbitrary visitor. They are only hit if a visitor is on the respective page. So Nemos advice is the way to go. --[[kgh]] (talk) 13:03, 3 December 2014 (UTC)

$wgUseETag

I want to point out that I had $wgUseETag true ever since but that's not needed with far-future expires headers. --Subfader (talk) 20:34, 25 March 2015 (UTC)

Serve images from a cookieless domain

I was surprised how easy it was to setup MW to use a different directory (on the same server). All it takes is $wgUploadDirectory and $wgUploadPath. --Subfader (talk) 11:55, 3 May 2015 (UTC)

Raise $wgResourceLoaderMaxage

If you're a one-admin-wiki you can raise the cache age of unversioned $wgResourceLoaderMaxage to multiple days. Push updates with $wgStyleVersion. --Subfader (talk) 13:52, 29 May 2015 (UTC)

404 handler / $wgThumbnailScriptPath

I don't quite understand why $wgThumbnailScriptPath is recommended.

My images and thumbs are stored on a CDN-like subdomain. With $wgThumbnailScriptPath all disadvantages are back (cookie, short cache expire etc). --Subfader (talk) 14:23, 29 May 2015 (UTC)