High Performance PHP with Serversaurus

This post outlines a number of infrastructure-level strategies that can be employed to improve the performance of PHP web applications hosted with Serversaurus.

Note that the best results will come from profiling and optimizing the web application before it hits the servers. However, the following strategies are services that Serversaurus can offer you at a server management level.

PHP received a very significant performance bump in the upgrade from version 5.6 to 7.x.

There are very minor improvements between PHP versions 5.4, 5.5, and 5.6. These are generally not worth pursuing for performance, but we suggest not using EOL PHP versions nonetheless.

Upgrading to PHP 7.x is a practically free way of buying performance, if the web application supports it.

Benefits

• Unrivalled performance
• Web application agnostic

Risks

• Does not know about the web application – it is entirely up to the developer to ensure the application does not exhibit behaviour that is cache-busting or otherwise pathological from Varnish’s perspective
• Requires fairly solid understanding of Varnish, the web application at the HTTP protocol level to leverage correctly

The traditional execution model for PHP is to exist as independent runtimes alongside forked Apache (mpm_worker) workers.

This is convenient because it permits use of Apache features such as .htaccess. However, this convenience incurs a very high overhead in comparison to other models.

Consider alternative execution models:

Benefits

• Provides improved execution model while remaining compatible with .htaccess
• Familiar cPanel environment
• No difference to regular shared hosting from developer point of view
• Can be combined with Varnish and PHP 7.x.

Risks

• No operational risks
• May not meet performance requirement for extremely high traffic sites

HHVM is a rewrite of the PHP runtime that is capable of optimizing and executing PHP 5.x code, much more efficiently than the official PHP runtime. It is a kind of “application server”, which exposes a FCGI interface, similar to PHP-FPM.

Like PHP-FPM, it is persistent, but is a single, threaded process.

Because HHVM is essentially a rewrite of the PHP runtime and all of its functions and modules, there are minor incompatibilities compared to the stock 5.x runtime. It is extremely important to test when using HHVM.

For this reason, it is also recommended, in a production deployment, to layer HHVM with PHP-FPM, and have the web server fall-back to PHP-FPM if the request fails to be served via HHVM.

If the web application is already PHP 7.x native, it is usually better to just deploy PHP 7.x with PHP-FPM.

Otherwise, it is very much recommended to ensure that the application works with PHP 5.6 before transitioning to HHVM.

In Serversaurus’ case study of a real-world Expression Engine/PHP-FPM 5.4 website, HHVM achieved a 10x increase in throughput (from 2.x req/sec to 25-30 req/sec), and a 8-10x reduction in TTFB (from 2-3sec to 200-300ms). This was with no code changes.

Benefits

• Extremely high (10x) performance improvement compared to PHP 5.x with PHP-FPM
• Targets PHP 5.x compatibility
• Ability to fail-over (and swap-in/out with PHP-FPM)

Risks

• Some probability of edge cases coming from minor compatibility issues
• Some minor functions and modules may be missing from HHVM
• Suffers from warm-up time when booting, but there are mitigations
• Almost total rewrite of PHP runtime means that total extent of risk is unknown

This strategy will not increase PHP performance. In fact, does not affect PHP whatsoever, but it is worth a mention due to its effectiveness.

Varnish cache is a web server which takes responses from PHP (or other backend), and stores them in their entirety for re-transmission to subsequent visitors.

It is capable of extremely high throughput (much more than any PHP runtime will ever be capable of), limited only by hardware interface. It is also extremely flexible and configurable.

However, it also has the highest developer overhead of any solution.

Many PHP frameworks and applications (e.g. WordPress and ExpressionEngine) exhibit behavior that makes their pages difficult to cache. i.e. they cache-bust by default.

For this reason, Varnish is best suited to web applications that are largely:

• Brochureware
• Festival websites that do not have a high degree of interactivity
• Well-understood by their developers, specifically regarding the use of sessions, partials that are unique to specific visitors etc.

As a rule of thumb, Varnish should not be used when:

• Sessions are always present AND used
• Pages contain content unique to specific visitors
• Page contents do not stay the same over subsequent requests
• Web application has low traffic, since cache will be cold

It is perfectly possible to use Varnish in those cases, and sometimes necessary given a volume of traffic. However the configuration complexity tends to grow very quickly at that point, and the use of Varnish becomes a development exercise rather than an infrastructure exercise.

It is possible to use Varnish on a white-list basis or a black-list basis, which can mitigate some of the risk.

Benefits

• Unrivalled performance
• Web application agnostic

Risks

• Does not know about the web application – it is entirely up to the developer to ensure the application does not exhibit behaviour that is cache-busting or otherwise pathological from Varnish’s perspective
• Requires fairly solid understanding of Varnish, the web application at the HTTP protocol level to leverage correctly

Serversaurus’ Performance Shared hosting provides an improved environment compared to Business Shared hosting with practically zero developer overhead.

It leverages ideas from the PHP-FPM solution, and provides users with a low contention, high CPU/Memory allocation, persistent execution model environment that remains compatible with .htaccess usage.

It is also likely to be more affordable than many of the solutions that are only compatible with Cloud Hosting services.

Benefits

• Provides improved execution model while remaining compatible with .htaccess
• Familiar cPanel environment
• No difference to regular shared hosting from developer point of view
• Can be combined with Varnish and PHP 7.x.

Risks

• No operational risks
• May not meet performance requirement for extremely high traffic sites