[HOME] [DOWNLOAD] [DOCS] [NEWS] [SUPPORT] [TIPS] [ISSUES] [DONATE]

speeding up whonix.org through caching

Website speed tests:

https://gtmetrix.com

https://developers.google.com/speed/pagespeed/insights/


Already using mediawiki caching settings for a long time.

## Shared memory settings
$wgMainCacheType = CACHE_MEMCACHED;
$wgMessageCacheType = CACHE_MEMCACHED;
$wgUseLocalMessageCache = true;
$wgParserCacheType = CACHE_MEMCACHED;
$wgUseGzip = true;
$wgEnableSidebarCache = true;
$wgMemCachedServers = array("127.0.0.1:11211");
$wgexLingoCacheType = CACHE_MEMCACHED;
$wgLocalisationUpdateDirectory = "$IP/cache";
## Set $wgCacheDirectory to a writable directory on the web server
## to make your wiki go slightly faster. The directory should not
## be publically accessible from the web.
$wgCacheDirectory = "$IP/cache";
$wgParserCacheExpireTime = 2592000;
$wgResourceLoaderMaxage = 2592000;
$wgEnableSidebarCache = true;
#enable file cache - https://www.mediawiki.org/wiki/Manual:File_cache
$wgUseFileCache = true; /* default: false */
$wgFileCacheDirectory = "$IP/cache";
$wgShowIPinHeader = false;
$wgDisableCounters = true;
## If on, the sidebar navigation links are cached for users with the current language set. This can save a touch of load on a busy site by shaving off extra message lookups.
## However it is also fragile: changing the site configuration, or having a variable $wgArticlePath, can produce broken links that don't update as expected.
$wgEnableSidebarCache = true;
## testing this cache setting
$wgFileCacheDepth = 0;
#$wgUseSquid = true;
#$wgSquidServers = array( '127.0.0.1:6081' );
#$wgUsePrivateIPs = true;
#$wgSquidMaxage = 1800;
## maybe needed for Varnish but not using Varnish anymore
#$wgCacheEpoch = wfTimestamp( TS_MW, time() - 86400 ); # 60*60*24 = 1 day
$wgInvalidateCacheOnLocalSettingsChange = true;
$wgUseESI = true;
$wgUseETag = true;

This already makes use of memcached.


Can’t use a single nginx server to be a web server and cache (proxy_cache) at the same time. It wouldn’t make sense either. Linux is already caching files on the disk. See:


Using nginx fastcgi_cache together with mediawiki might make sense, but I always get cache MISS and cache isn’t populated. (Works for whonix.org/index.php but not needed since currently not using PHP.) No useful web search results. All information is years old.


discourse is quite slow. But does not look like a lot can be done.


CDN’s are probably not an option? Because a lot of them block Tor users. (And are USA companies.) And even if not blocking Tor, they’re a permanent “MITM”. It’s not clear if these would actually reduce security but it would probably be criticized.


Potential future enhancements:

https://www.nginx.com/blog/responsive-images-without-headaches-nginx-plus/

https://packages.debian.org/buster/libnginx-mod-http-image-filter

https://www.ngxpagespeed.com/

https://www.modpagespeed.com/doc/download

1 Like

Discourse is described as a JS app rather than a website with html/css so traditional caching methods like Varnish are useless.

Some suggestions were looking into optimizing the Redis database loads, disabling forced image loading, implementing lazy loading

1 Like
[Imprint] [Privacy Policy] [Cookie Policy] [Terms of Use] [E-Sign Consent] [DMCA] [Investors] [Priority Support] [Professional Support]