WordPress and Apache/PHP Internal performances
This one was not really hard, as an enormous bunch of tools exists for WordPress.
The chosen ones where :
- W3 Total cache for WordPress optimization/static content generation
- pecl-APC for PHP’s opcode caching
Nothing fancy here. No in-depth configuration.
apt-get install php-apc && /etc/init.d/apache2 restart
W3 Total cache
Could be easily installed in the WordPress Administration Backend.
Configuration is very specific and suited for working with the 2 next points (Routing Static Content / RAM-Caching).
In a nutshell, the idea is to use Opcode APC’s for every internal caching, and then make Page Caching to the disk as static HTML pages. These pages will then be delivered blazing-fast with the Static Content delivery solution (Nginx, in fact), and then RAM-Cached by the caching Frontend (Varnish-cache, in fact) thanks to the Browser Cache function.
In General Configuration page :
Page caching is the very least caching we should enable.
Beware : it absolutely should be configured to Disk: Enhanced and not to Opcode: Alternative Php Cache(APC).
This is because we actually want wordpress to generate static html files. We will then retrieve them with our fast Routing/Static delivery middle-end we’ll configure in point 2.
- your site will profit a lot of it on YSlow and PageSpeed score. (verify at gtmetrix)
- Readers with low-speed connections will benefit a lot
As the result of minifying will be made static within disk (Page Caching), this will best fit in Opcode Cache (APC).
- We’ll use Object Caching which is really better
- We’ll deliver 99% of static content and won’t use Database when doing such
BrowserCache also should absolutely be enabled.
BrowserCache will send cache instruction through special HTTP headers which will normally be used by browsers to keep cache on your harddrive, but this time will be used by Caching Frontend as instruction to keep in-RAM cache.
This is, along with Page Caching, the Load-Bearing Wall of all our final performance gain.
Any other option (CDN, Varnish Purging, Cloudflare…) should not be enabled at all.
Please also understand that our future settings will not be compatible with the Cloudflare solution.
In Page cache Configuration page :
- Logged users Cache will be desactived by the Caching Frontend itself
- Caching Frontend will not handle caching of pages containing cookies
- Logged users should always access to an up-to-date Administration Backend and to an up-to-date Comment status
The reasons why the Caching Frontend will not handle caching of cookie-enabled page is quite obvious, as we don’t want cookies and content of User1 delivered to User2, specially for WordPress Administration operations. This is even more true about eCommerce software, where you clearly don’t want to mess up shopping carts between users.
Any other settings in W3 Total Cache could and should be left intact.
Now click on the Empty Cache button at the top.
Time to change Apache listening port.
Apache should now be bind to another port (8080 for example), as it will now be only a code-execution backend for when :
- Static pages are not existing at all
- Static pages are not up-to-date
- Users are logged-in
Which should not concern more than 1% of your traffic.
Under Debian 6 (your job to find where this is on your favorite distribution), edit /etc/apache2/ports.conf for these two lines :
NameVirtualHost *:80 Listen 80
Change it to:
NameVirtualHost *:8080 Listen 8080
Then correct your Virtual Host definition in /etc/apache2/sites-available/default (or whatever your VirtualHost file is) :
<VirtualHost *:80> ServerName blog.brigato.fr [...]
Change the Port definition :
Restart Apache server and verify that it now binds on port 8080 :
/etc/init.d/apache2 restart && (netstat -lpn | grep apache2) Restarting web server: apache2 ... waiting . tcp6 0 0 :::8080 :::* LISTEN 19773/apache2
At this time, a new benchmark should now provide an upgrade in performance from a factor 3 (16rq/s) to 5 (25rq/s) depending on your harddrive speed and I/O. For me it is 17 requests/s as my disk is a poor old SATA on a shared datastore.
Theses performances :
- Are final for the apache part
- Will be the performance you will get in your administration backend, which still should be enough
- Will make your final performance very good, as 1rq/s on Apache will be ~380rq/s on Caching Frontend