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)