Scalable WordPress Architecture

At Elastisys, we recently launched Scalable WordPress, the easiest way to get a highly scalable WordPress site up and running. It offers great performance, caching at several levels, full automation, and includes our patented predictive auto-scaling solution to make sure your site has the optimal amount of capacity for the number of users. As the principal architect and developer on the project, I have faced many challenges in making every component fit just right and play nice with the others. Get a nice cup of your favorite beverage and join me in this exploration of the software architecture powering Scalable WordPress.

The Scalable WordPress Architecture

Without further ado, let us look at the architecture itself, complete with labeling and network traffic flow:

Let's look at each component individually, using network traffic flow as our guide through the system. Network traffic flow is important, as it relates directly to what WordPress is really all about: displaying your beautiful content to your visitors.

Optimal Network Traffic Flow

When you have done your part in creating engaging content, your web servers need to do their part in serving that content as quickly as possible. Learn how Scalable WordPress performs high-performance delivery of your content.

Load balancing using multiple HAProxy load balancers

When a visitor accesses your site, their web browser will first determine what IP address your domain name resolves to by using DNS (Domain Name System). It translates something fairly memorable like "elastisys.com" into something decidedly less memorable like "77.81.188.43". Once the browser knows that, it can initiate the connection. For performance or fault-tolerance reasons, you may wish to have multiple servers registered for a single domain name: should one be overloaded or fail, the other will help share the burden or take over entirely. Because we want Scalable WordPress to handle deployments of any size, we support running multiple HAProxy load balancers as the initial server that will start handling the visitor's network traffic. Just make sure to update your DNS records to point to all of them (can be automated in certain clouds). Easy peasy!

SSL Termination via Nginx

A web browser uses HTTP (Hypertext Transfer Protocol) to talk to the web server. It is a simple language revolving around verbs ("get", "post", "delete", and "put" being the most common ones) and nouns (the actual web pages or services in question). If a visitor uses unencrypted HTTP, the request will go directly from the load balancer to the Varnish cache layer in Scalable WordPress.

However, for security reasons, the connection to the web server can be encrypted. This means that both the web server and the web browser have to perform computationally rather intensive work encrypting and decrypting each other's requests and responses. Also, each such encryption communication is unique: if you and I access the same web page at the same time, we would still get uniquely encrypted responses from the web server although the decrypted actual contents of the page might be the same (a blog post, for instance).

Because each SSL connection is unique, a high-volume web site will spend considerable amount of computational resources on encryption. For this reason, high-traffic sites use SSL termination early along the request's processing path. This lets the other servers in the architecture be unconcerned about spending processing power on encryption.

Essentially, SSL terminators strip away the encryption and pass the HTTP request along to other servers. When the response comes back, they encrypt it, so that the visitor gets their uniquely encrypted response. Scalable WordPress uses nginx as its SSL terminator of choice.

Caching via Varnish Cache

Caching is all about keeping responses for requests around for a while in memory so that if request comes in for which we already have a response, it can be fetched from memory rather than be constructed yet again. Ensuring that responses can be cached is key to operating a highly scalable web site.

Scalable WordPress uses Varnish HTTP Cache for caching, configured to know whether a request came in via regular HTTP or HTTPS, since certain WordPress pages behave differently depending on whether the request was made in a secure manner or not (although the aforementioned SSL terminators have decrypted the request before it hits Varnish, it has also marked it appropriately using HTTP headers).

However, Varnish cannot blindly cache everything, since that would make your dynamic WordPress site behave entirely like a static site. That would be devastating if you use your WordPress site for e-commerce, for instance -- what if visitors got inconsistent views of stock availability and you could not deliver? For that reason, Varnish is configured to rely on learning which resources can be cached from the WordPress application running in the web server.

WordPress Web Server with Apache and W3 Total Cache

WordPress is a very nice framework for building your perfect web site. It is very simple and basic out of the box, and relies on its thriving ecosystem of plugins to accommodate various needs and to provide advanced functionality. In its most basic form, WordPress naively processes each and every page view by accessing a MySQL-compatible database to answer queries and stores uploaded files and other media locally on the file system. Also, each page specifically states that is shall not be cached, since WordPress wants to re-generate it when the visitor views it again. This approach makes WordPress simple, but performance is bad when multiple visitors access the site at the same time.

WordPress can be made much more cache-friendly by installing the excellent W3 Total Cache plugin. It optimizes WordPress from the inside out in too many ways to list here. The important part is that the Scalable WordPress architecture offers W3 Total Cache all the resources it needs to truly shine: a networked file system, in-memory caching of objects (a typical WordPress page is made up of many objects), and a replicated MySQL database.

The result is an easily configured WordPress server, all configurable using the graphical admin user interface, that is a high-performance powerhouse. W3 Total Cache interacts with all related components in the Scalable WordPress architecture, and manages it for you.

Replicated MySQL Databases

WordPress stores everything that is not uploaded media files about your web site in its database: textual content of pages, posts, and comments, and metadata about media files such as the descriptions and captions. To generate a page, the database will have to be queried many times. If caches are not used, this quickly becomes a performance bottleneck. Luckily, W3 Total Cache provides such a cache, but the database is still not off the hook: it may still be queried many times for a high-traffic web site. Scalable WordPress replicates the database onto many servers, which helps not only with availability, but also performance for the same reason as we support multiple load balancers: failure or resource exhaustion of one should not be the end of the story!

In-memory Object Storage via memcached

If W3 Total Cache is able to cache many things, where does it actually store the cache? If it would just store it locally on each web server, other web servers would not benefit from it: responses could be cached on server A, but server B would need to generate the response from the start. Obviously, this would not be ideal. Enter memcached, a high-performance key-value store. W3 Total Cache is easily configured to make use of it, and thereby offloads your web servers and database tremendously. True to Scalable WordPress architectural design, we of course support running multiple memcached servers.

Networked File System via GlusterFS

Media files such as images and video accompany almost all posts on a blog these days, and WordPress stores them on the file system. That is also where all WordPress plugins and its configuration reside. Any changes to the file system are therefore crucial to spread to all WordPress web servers, immediately. This is where the high-performance networked file system GlusterFS comes in. Any change made by any web server in Scalable WordPress will be practically instantaneously visible to all others. Updating WordPress when a new security fix is available? No problem! Changing a media file, such as editing an image? Immediately served by all WordPress servers.

Closing Remarks

So that is the architecture behind Elastisys Scalable WordPress. It includes everything you would hope to find in a truly scalable WordPress installation, and it is configured by our engineering team to dynamically reconfigure itself as the deployment grows and shrinks.

In an upcoming post, I will describe the automation that holds the entire system together, and makes it possible to monitor and scale each component individually.

In the mean time, be sure to contact Elastisys and request a demo! Or just visit our website, since it is of course deployed on Scalable WordPress.