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

Pecl-APC
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.

Minify has a very little impact on the performance. However :

• 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).

Database caching should not be enabled for two reasons :

• We’ll use Object Caching which is really better
• We’ll deliver 99% of static content and won’t use Database when doing such

Object Caching should be enabled as a best fit replacement of Database Caching.
Will best benefit on Opcode Cache (APC) as further static generation will be done (still Page Caching).

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 :

You should cache as much pages as possible, specially the home page.
Logged users still should not benefits from the cache for three reasons :

• 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 :

<VirtualHost *:8080>

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