- Consider /var/cache/pagespeed which better matches FHS for nginx-module-nps (directory must be created upon install)
Compile kernel and software via -O3 flag
Varnish cache clear with WordPress website produces high load
The mechanism commonly used for complete cache invalidation in Varnish is bans. Our Varnish config allows for CPU-friendly ban mechanism (ban lurker). However, bans on a busy website result in slow response for first time page visits (after clearing cache).
A more effective way for clearing cache, that will be deployed is xkey. It requires your WordPress to be equipped with a plugin to send Surrogate Keys header – to tag pages.
Solution: We will develop our own WordPress plugin or modify existing like Purgely. Recent improvement for single page cache purging already includes soft purging.
Design principle: the plugin will add xkey header with “wordpress” key for WordPress generated pages (purging that key will allow to clear entire WordPress cache without further delays for visitors), and in addition to that it will add other useful keys in order to clear relevant pages when updating a post, widgets, etc.
The benefit to all above is: the visitors will not get slow response times while content in cache is being refreshed. They will be getting slightly stale cached versions while content is being refreshed in background (Varnish grace).
We will be providing centralized installation of Varnish Dashboard and client control panel on our server (Varnish Agent is already installed on Citrus servers)
We will consider installing it centrally in your client control panel
We will get additional configuration improvements from open source solutions, e.g. debops. We will support Varnish 5 and investigate into using Hitch for SSL termination.
We will be putting VSL directory to Ram Disk on busy servers.
Kernel tweaks and Nginx