Skip to main content
  • Updated

Pagely's NGINX+Apache and NGINX-Only Modes

Pagely supports two different web server modes:

The default mode is NGINX+Apache. There is another mode we refer to as NGINX-only. NGINX is always at the front of the stack; there is no Apache-only mode.

This article will explain the differences and provide you with some useful information about each one. You are able to selectively pick and choose which sites operate in whichever mode, making it easy to set up a staging version of your site to try out before making the switch!

NGINX+Apache Mode (Standard)

NGINX+Apache mode has NGINX handling all of the incoming traffic and acts as a caching layer. You still benefit from the high performance of NGINX superior connection handling and full page caching features while maintaining the ability to implement rules through .htaccess files. This layout is the most familiar to anyone who has used a LAMP stack in the last, well... forever. NGINX proxies all dynamic requests to Apache which in turn communicates with the PHP-FPM worker pools that exist for each site.

Pros:

  • Familiar and instantaneous activation of .htaccess rules.
  • Maximum compatibility with most WordPress plugins which require custom .htaccess rules in order to function.

Cons:

  • Large influx of un-cacheable requests can lead to long request times, timeouts, and server load.
  • Advanced features such as PressThumb and S3 asset proxying are not available.
  • No syntax checking on .htaccess files - a malformed line can instantly break your site!
  • No default fast-handling of 404s on assets, resulting in triggering WordPress' 404 page generator. While this can be configured in Apache as well, it is not a default setting. A large influx of 404s can overload your server.

NGINX-Only Mode (Optional)

NGINX-only mode is the next generation web server configuration offered by Pagely. This super-tuned configuration has many benefits over the standard NGINX+Apache mode.

Primarily, fast-handling of 404s on assets and a pressure relief system work to keep your server running stable. Since this mode interfaces directly with PHP-FPM without proxying through Apache, there are fewer moving parts in the stack and makes everything run just a little bit better.

Certain advanced features are available only when in NGINX-only mode, making the switch to it a prerequisite before they can be enabled. While you do lose the ability to configure rules through a .htaccess file, additional rules can be made at your request. Due to the stability of these custom configuration directives, they can be fully checked for valid syntax before activating, which increases predictability in your deployments.

Pros:

  • Better performance overall, compatible with most WordPress standalone and multisite environments.
  • Out of the box fast handling of 404s for static assets, reducing the chances of a request needing PHP to be served.
  • Configurable connection limits to help maintain server stability.
  • Flexible enough to configure a litany of additional features.
  • Testability of config file changes before activation.

Cons:

  • Slight learning curve to re-implement common .htaccess rules in NGINX format, but straightforward overall. Our Support Team can assist you with this if needed!
  • Sites with many .htaccess rules will need more prep work to enable. If you just have the standard WordPress lines in your .htaccess file, this is already covered in the default NGINX-only mode ruleset.
  • While a configtest tool is available, failure to address a bad custom config can prevent NGINX from starting up properly if the service goes down or your server has to reboot unexpectedly. If this ever happens, chances are that our Operations team has been alerted and investigating.
  • Applying new rules requires logging in to the server over SSH, or you may ask Pagely's Support Team to handle it for you.

Why Switch Modes?

The biggest reason for switching your site to NGINX-only mode is the built-in pressure relief valve. What this means is when the server gets overloaded with too many dynamic PHP requests, the server will return a 503 Service Unavailable message to a small subset of requests until the PHP worker connection slots free up.

It's helpful to think of each site having a bucket that holds incoming dynamic requests until they can be processed by PHP. Each site has both an NGINX bucket and a PHP worker pool. If the PHP worker pool is full, the NGINX bucket will start to fill up as well. When both are full, any cached content will still continue to serve quickly and without any error messages. However, any dynamic content can potentially return a 503Service Unavailable until the backlog clears up.

While at first this may seem counter-intuitive, it is actually a great way to keep your server from getting overloaded. Remember that when all of your PHP workers are busy, it means the requests are blocking due to CPU/RAM limitations, Database Latency, or long-running server side HTTP requests. In any of these situations, you don't want to send more dynamic requests to your server until things clear up so that the server has the maximum resources available to serve the existing requests. The same situation in the standard NGINX+Apache mode will result in requests that seem to spin and take forever to return, often times leading to 499 client-side web browser timeout or 504 Gateway Timeout messages. Neither of these are an ideal scenario for your visitors, and it should be a priority to address whatever is causing the problem.

This self-stabilizing mechanism helps keep existing requests serving quickly. For the small subset of requests that it can't serve due to a full bucket, it will return a 503 message very quickly. As soon as the connection queue clears up, dynamic requests will be accepted again automatically.

If you are frequently experiencing 503 messages after enabling NGINX-only mode, this is an indication that your dynamic content is taking too long to return content. While the connection limits can be tuned without upgrading your server plan, consistently recurring 503s is a sign of trouble somewhere within your application. Pagely's Support Team can help to pinpoint the cause of these slow requests and often times will provide quick fixes for you too. The goal is to return any type of request in under 2 seconds on average.

Generally, if your site has a good cache HIT rate, NGINX-only mode is a smart move to make. Your server and your visitors will thank you!

Related articles