From the support desk: powering our WordPress stack: Nginx

This month’s support desk article looks at Nginx on our WordPress plan – exactly what it is, why we chose it, and what it means for hosted sites on this platform.

At the heart of our WordPress Hosting platform is the Nginx Web server and proxy; it’s a core piece of our hosting stack and is one of the primary reasons our Managed Hosting is so fast and scalable, but what does it do and how does it help us?

What’s a web server?

More accurately an HTTP server, Nginx is software which serves assets to web browsers and other clients from your server. It handles the connection of the browser to the server, along with any SSL certificates and handshakes to make sure the connection is secure, then picking what asset the browser asked for and how to respond. Nginx is not the only Web Server on the market with Apache, IIS and Lightspeed being other popular web servers.

What’s a proxy?

A proxy is software which takes requests and then asks another piece of software for the results, then presenting the results as if it came from itself. In the case of Nginx it might be proxying PHP-FPM, another site or just about anything. Other popular proxy software includes HAproxy and Traefik.

Nginx vs. traditional LAMP stack

A traditional hosting setup is normally referred to as a LAMP stack which stands for Linux, Apache, MySQL & PHP.  In this stack Nginx replaces Apache. There is nothing wrong with Apache it is the workhorse of the internet and powers millions of sites, including many on our other products. Part of the reason for Apache’s prominence is that it is very flexible, meaning it can cope with just about anything you can throw at it. It also has a very modular system making it easy to extend with third party modules.

When it comes to performance, some of these benefits actually turn into hindrances as every extra module or capability is taking away from some other aspect of performance. Apache therefore, perhaps unfairly, has a reputation of being slower than most of its rivals.

On our WordPress Hosting we know exactly what we are hosting (WordPress) and also control the setup, so we don’t need the flexibility that Apache brings.

Apache and Nginx are also architecturally different.  Apache scales for busy sites by spawning lots of processes and trying to juggle incoming connections between them, where Nginx takes the approach of having a master process that passes work to workers, with each worker capable of handling multiple connections. This allows much easier scaling when you have lots of concurrent connections (many visitors to your site).

Passing to PHP-FPM

One of the differences between Apache and Nginx is that Nginx is just a webserver and proxy; it doesn’t handle dynamic content like PHP itself.  Instead, it hands such content over to a handler like PHP-FPM. This might initially sound like a negative but this separation of concerns allows Nginx to focus on doing what it’s good at; retrieving and delivering static content and proxying to other sources.

HTTP/2

Nginx has built in HTTP/2 support, allowing any site hosted with us using SSL to automatically use HTTP/2.  If a visitor’s browser also supports HTTP/2, assets can be pushed via HTTP/2 push, resulting in a faster experience for them. On our WordPress Hosting this means clients can push assets such as css or javascript via the Link header.

Caching

While having a small, light and performant web server handling requests brings instant speed improvements, we can really see bigs leaps when we introduce caching and specifically Nginx Fast-CGI cache which allows us to cache the results of PHP pages. Within our hosting, we refer to this as the Full Page Cache.

The full page cache stores the output of the PHP-FPM handler, which is normally the fully generated pages, in RAM. The next attempt to access the page is then retrieved from RAM and not passed to PHP-FPM.  Retrieving a stored page from RAM rather than recreating it on the fly is hundreds of times quicker.

Caching right at the server level means no expensive calls are made for the vast majority of visitors to a hosted site. We actually have two versions of the cache, one for desktops and another for mobiles, to allow clients to serve different content on desktop and mobile devices.

When something doesn’t hit the cache, Nginx will hand it off to PHP-FPM to generate. We do this for all GET requests unless they have a query string, send an appropriate bypass header or have a cookie on our bypass list. This means that logged in users or shopping carts won’t get cached.

With caching we can take a site from handling a few dozen concurrent connections to thousands if they are hitting the cache.

Rate Limiting

To help further reduce stability issues at scale, WordPress hosting uses rate limiting on an individual basis for PHP-FPM requests within Nginx. Nginx has good rate limiting options and we only rate limit PHP-FPM requests which occur if the page isn’t cached. We do allow a generous number of requests as the WordPress admin area can make lots of ajax based requests, combined with the ability to burst to make sure actions like using the Block Editor are still possible. Limits are on individuals, so the number of visitors would not affect rate limiting and if a user receives a 429 HTTP response, it doesn’t mean others will be affected.

Using Nginx as a traditional Proxy

Whilst we use Nginx as a proxy for PHP-FPM we also use it to proxy other sites. One of the things we can do is proxy Professional or Universal Hosted sites onto WordPress Hosting, for example allowing the use of Magento on a /shop/ URL where Magento is hosted on a Universal Hosting account. By using the proxy option we can not only have sites not on the hosting being proxied to an endpoint on the hosted site, but also gain the advantages of the caching, rate limiting and gzip options.

We can also proxy third-party assets, to allow them to use our browser leverage and gzip caching options, for example proxying Google Analytics scripts or fonts.

So what are the downsides?

The biggest downside for our clients compared to Apache is the lack of customisation, for example there is no .htaccess or equivalent. This means things like redirect either have to be done at the application level (WordPress) or be added as location block in the Nginx server configuration. This means Nginx remains highly performant but this lack of customisation can at times frustrate people new to using the server.

Nginx is our daily workhorse – we use it on thousands of sites; it’s fast, it helps us keep our stack secure and while it may at first seem inflexible it provides enough flexibility to allow us to manage almost any WordPress site without any custom configurations.