A Look At The Modern WordPress Server Stack

About The Author

Carl has been coding since he was 8 years old. As of late, he has been doing mostly “web” stuff. A lot of it has been around PHP and WordPress. … More about Carl ↬

Email Newsletter

Weekly tips on front-end & UX.
Trusted by 176.000 folks.

Quick summary ↬ Editor’s Note: Today marks a special day for WordPress. Powering many websites (and yes, slots empire bonus codes Magazine is one of them), it celebrates its 13th birthday today. Happy birthday, dear WordPress! Here’s to many more! Do you remember when you could run a “fast” WordPress website with just an Apache server and PHP? Yeah, those were the days! Things were a lot less complicated back then. Now, everything has to load lightning-fast! Visitors don’t have the same expectations about loading times as they used to. A slow website can have serious implications for you or your client.

Do you remember when you could run a “fast” WordPress website with just an Apache server and PHP? Yeah, those were the days! Things were a lot less complicated back then.

Now, everything has to load lightning-fast! Visitors don’t have the same expectations about loading times as they used to. A slow website can have serious implications for you or your client.

Further Reading on slots empire bonus codes Mag:

  • with it that is still open.

    Meanwhile, the nginx HTTP cache system is robust and well documented. You can use it as a normal HTTP cache or as a smaller yet effective micro-cache. It’s just one more reason why nginx is the preferred web server nowadays.

    Add Varnish to the Stack

    What is Varnish? It’s a dedicated HTTP cache server (or, as its developers like to call it, HTTP accelerator). Most high-traffic websites and premium hosting companies use it as their HTTP cache solution.

    They use it because it’s powerful and offers the most flexibility. Varnish has its own configuration language, called VCL. It lets you control every element of the caching process. Varnish also comes with a lot of tools for analyzing what the cache is doing and how it’s performing.

    These are the major differences between using it and just using the built-in web server HTTP cache. The built-in web server HTTP cache is super-performant but also pretty basic. You don’t have a lot of control beyond a few configuration options.

    Nevertheless, this power and flexibility come at a price. Varnish is also the most complicated HTTP cache option. It does nothing but cache HTTP responses. It doesn’t handle SSL termination, which most WordPress developers want (or should want). This means that our modern WordPress server stack is going to be more complex when we use it.

    Varnish HTTP cache

    The diagram above illustrates this extra complexity. We now have two more components in our WordPress server stack: Varnish and a reverse proxy.

    The reverse proxy is there to overcome the limitation that Varnish has with SSL. It sits in front of Varnish and decrypts the requests that our server receives. You can also call this type of reverse proxy an SSL termination proxy. The proxy then sends these decrypted requests to Varnish to process.

    Once a request hits Varnish, the VCL configuration file(s) kick in. They’re Varnish’s brain. For example, they tell it how to:

    • analyze, clean up and modify incoming requests;
    • look for a cached response;
    • analyze, clean up and modify returning responses from WordPress;
    • cache these returning responses;
    • handle a request to remove one or more responses from the cache.

    This last one is especially important. Left to itself, Varnish has no way to know when WordPress wants to remove a page from the cache. So, by default, if you make changes to a post and update it, visitors will keep seeing the same cached page. Luckily for us, a plugin exists that removes pages from the Varnish cache.

    WordPress

    All right, our request for the home page of modern.wordpress-stack.org has hit WordPress. It went through the request-response cycle that we just covered. The HTTP cache did everything it could to find an HTTP response to send back.

    But there was no cached HTTP response to send back to the browser. At that point, the HTTP cache had no other choice. It had to forward the HTTP request to WordPress.

    It’s all in WordPress’ hands now. WordPress has to turn our HTTP request into an HTTP response and send it back to the HTTP cache. As we saw earlier, this is the main bottleneck of our whole modern WordPress server stack.

    The cause of this bottleneck is two-fold. WordPress has a lot PHP code to execute. This is time-consuming, and the slower PHP is at doing it, the longer it takes.

    The other bottleneck is the database queries that WordPress needs to perform. Database queries are expensive operations. The more there are, the slower WordPress gets. This will be the focus of the last section on the query-result cycle.

    Optimizing The PHP Runtime

    Let’s get back to PHP. At this moment, WordPress has a minimum requirement of PHP 5.2. This version of PHP is almost 10 years old! (The PHP team stopped supporting it in 2011.)

    The PHP team hasn’t been sitting idle all those years. Numerous performance improvements have been made, especially over the last few years. Let’s look at what you can do to optimize it nowadays.

    Use the Latest Version of PHP

    The easiest thing you can do is upgrade your version of PHP. Versions 5.4, 5.5 and 5.6 all saw performance improvements. The largest improvement was from 5.3 to 5.4. Switching to it increased the performance of WordPress by a decent amount.

    Install Opcode Caching

    Opcode caching is another way to speed up PHP. As a server-side scripting language, PHP has a big flaw: It needs to compile a PHP script each time it executes it.

    The solution to this problem is to cache the compiled PHP code. That way, PHP doesn’t have to compile it each time it executes it. This is the job of the opcode cache.

    Before PHP 5.5, PHP didn’t come bundled with an opcode cache. You had to install it yourself on the server. This is another reason why using a more recent version of PHP is better.

    Switch to a Next-Generation Compiler

    The last thing you can do is switch to one of the two next-generation compilers: either Facebook’s HHVM or PHP 7, the latest version of PHP. (Why PHP 7? It’s a long story.)

    Facebook and the PHP team built these two compilers from the ground up. They wanted to leverage more modern compilation strategies. HHVM uses just-in-time compilation, whereas PHP 7 uses ahead-of-time compilation. Both offer incredible performance improvements over good ol’ PHP 5.

    HHVM was the first one to arrive on the scene a few years ago. A lot of top-tier hosts have had a lot of success with it, offering it as their primary PHP compiler.

    It’s worth stressing, though, that HHVM isn’t an official PHP compiler. It’s not 100% compatible with PHP. The reason is that HHVM isn’t just designed to support PHP; it is also a compiler for Facebook’s Hack programming language.

    PHP 7 is an official PHP compiler. It hasn’t been around for a long time. The PHP team released it in December of 2015. This hasn’t prevented some WordPress hosting companies from supporting it already.

    The good news is that WordPress itself is 100% compatible with both compilers! The bad news is that not all plugins and themes are, because the minimum PHP version for WordPress is still 5.2.

    Nothing is forcing authors to make their plugins or themes work with these compilers. So, you can’t go all in with one of them. Your stack should always fall back to PHP 5.

    Query-Result Cycle

    At this point, the PHP runtime is going through all of the WordPress PHP files and executing them. However, these WordPress PHP files don’t contain any data. They only contain the WordPress code.

    The problem is that WordPress stores all of its data in a MySQL database. So, to get to it, the PHP runtime needs to query that database. The MySQL server returns the result of that query, and the PHP runtime then continues to execute the WordPress PHP files… well, that is, until it needs data again.

    This back and forth can happen from a few dozen times to a few hundred times. (You might want to speak with your developer if it’s the latter!) That’s why it’s a major bottleneck.

    Optimizing The Query-Result Cycle

    The optimization goal here is to speed up the execution time of WordPress files by PHP. This is where database queries are problematic. They tend to take more time than just running plain PHP code (unless your code is doing something outrageous).

    The obvious way to fix this problem is to reduce the number of queries that WordPress needs to perform. And that’s always worthwhile! But it’s not something the modern WordPress server stack can help with.

    We might not be able to reduce the number of queries that WordPress makes, but we aren’t out of options either. There are still two ways that the stack can help us optimize the query-result cycle. It can reduce the number of queries made to the database in the first place. And for those queries that make it to the database, it can decrease the time it takes to run them.

    These two options are both meant to do the same thing: make PHP wait as little as possible for results from the database, which will make WordPress itself faster.

    Stack Elements For The Query-Result Cycle

    Let’s look at the different stack elements involved in the query-result cycle. This part of the stack is less complex. But it still involves more than one component — namely, the MySQL database server and the object cache.

    MySQL Database Server

    A few years ago, a MySQL database server would mean the same thing to everyone. It was a server with the MySQL server installed. But things have changed a lot in recent years.

    Various groups weren’t happy with how Oracle was managing the MySQL project. So, each group forked it and created its own version that you could “drop in” instead. The result is that there are now several MySQL database servers.

    The new “official” MySQL server is the MariaDB server. It’s the community-developed version of MySQL server. The community plans to maintain full compatibility with the MySQL server project.

    Another popular alternative to MySQL is the Percona server. Unlike MariaDB, Percona is more of a branch of MySQL. Its developers aren’t against the MySQL project itself; they just want to focus on improving MySQL’s performance. The MariaDB team later merged some of these performance improvements into the MariaDB project.

    At the end of the day, you can pick the one you prefer. There’s no difference in performance between a Percona server and a MariaDB server (for most of us anyhow). They both perform better than MySQL. Percona does, however, maintain closer compatibility with the Oracle project.

    What does affect performance is the storage engine that the WordPress database uses. The storage engine controls how the database server manages the data it stores. You can also set a different storage engine per database table; you don’t have to use the same one for the entire database.

    A database server has several storage engines. We’re not going to look at all of them. Only two interest us: InnoDB and MyISAM.

    By default, WordPress uses the default MySQL database engine. Before MySQL 5.5, that engine was MyISAM. If you run a small WordPress website, then MyISAM is fine. MyISAM runs into performance issues once a website grows in size. At that point, InnoDB is the only choice for a database engine.

    The only issue with InnoDB is that it requires some tuning to perform at its best. If you’re running a large database server, you might need to adjust things. Luckily for us, there’s a tool to help with that.

    MySQLTuner is a small script that analyzes your database server. It will generate a report and give you tuning recommendations.

    Object Cache

    The brunt of the work of optimizing the query-result cycle lies with the object cache. The job of the object cache is to store data that is time-consuming to get or generate. As you might guess, database queries are a perfect candidate.

    WordPress uses the object cache a lot. Let’s say you use get_option to get an option from the database. WordPress will only query the database for that option once. It won’t query it again the next time someone needs it.

    Instead, WordPress will fetch the query result from the object cache. This is a proactive step that WordPress takes to reduce the number of database queries that it needs to make. But it isn’t a foolproof solution.

    While WordPress will do its best to leverage the object cache, a plugin or theme doesn’t have to. If a plugin or theme makes a lot of database queries and doesn’t cache the results, the stack can do nothing about it.

    In such cases, most of the database queries will come from WordPress itself. So, you’ll get great mileage out of WordPress’s built-in use of the object cache. That’s why it’s an important element of the modern WordPress server stack.

    Now, a problem with the object cache is that it doesn’t persist the data it stores by default. It just stores data in memory while PHP is executing all of the WordPress files. But once the PHP process terminates, all of the data that it stored in memory gets cleared.

    This isn’t ideal at all. An object cache could stay valid for a long time, so you don’t want to limit it to a single request. The solution is to use a persistent object cache.

    A persistent object cache often comes in the form of a plugin. That plugin would make use of the object-cache.php drop-in to do its job. This drop-in lets plugin authors change the default behavior of the object cache.

    The plugins then connect the object cache to a persistent data store. They do that by replacing the fetch and save functionality of the default object cache. Instead of saving and fetching data to memory, the object cache does it from that store.

    Persistent Object Cache Plugins

    Nowadays, there are two popular data store options for persistent object caching:

    Both of these data stores use RAM for storage, which makes them lightning-fast. In fact, their performance is comparable to that of the default object cache.

    The only problem is that they don’t come preinstalled on servers. And neither does their PHP extension (which is optional with Redis). You need to install one before you can use the corresponding WordPress plugin.

    Which one should you install? In practice, there isn’t much of a difference between the two for object caching. In the past, the popular option was Memcached. This has changed over the last few years. Redis has added a lot of features that have made it the go-to option for object caching.

    Getting Your Own Modern WordPress Server

    So, how do you get your own server? The obvious way is to get one from a top-tier WordPress hosting companies. These companies want to stay at the forefront of the WordPress hosting business, which motivates them to adopt the latest breakthroughs and technologies.

    But what if you want one without breaking the bank? A couple of tools are available to anyone who would rather do it themselves and pay less for hosting. Let’s look at them.

    DebOps for WordPress

    DebOps for WordPress is a tool that I built to help anyone build a modern WordPress server. Its mission is to make the modern WordPress server stack available to anyone in the community. That’s why I’m trying to make it as easy to use as possible. You don’t need any system administration knowledge to use it.

    DebOps for WordPress configures a server with the following:

    • HHVM (until PHP 7 makes it into an official Linux repository)
    • MariaDB
    • nginx
    • Redis
    • Varnish

    The tool does more than just configure a server with the latest technologies. It also takes care of securing the server for you. This is something that people often overlook when managing their own server.

    EasyEngine

    EasyEngine is a command-line tool designed to help you set up a WordPress website on a server. The great thing about EasyEngine is its flexibility: You can use it set up almost any combination of server technologies that we’ve looked at so far.

    For example, it lets you set up a server with either HHVM or PHP 7. It lets you chose between Memcached and Redis for your persistent data store. And it lets you install administrator tools such as phpMyAdmin.

    It also offers a large number of options when it creates a WordPress website. You can tell it to set up a website with an HTTP cache using a plugin or nginx. All of this flexibility is why EasyEngine is such a popular tool.

    Trellis

    Trellis is a tool developed by Roots. Like DebOps, it configures the server with a specific set of server technologies:

    • MariaDB
    • Memcached
    • nginx
    • nginx HTTP cache (optional)
    • PHP 7

    One thing to know about Trellis is its relationship to Bedrock, another tool built by Roots. Bedrock is a boilerplate for structuring a WordPress website around the “Twelve-Factor App” principles.

    The Roots team created Trellis to enable people to configure a server that uses Bedrock-structured WordPress website(s). You can’t use it with a normal WordPress installation, so keep that in mind.

    Times Have Changed

    As you can see, a WordPress server has a lot more moving parts today! But this doesn’t need to be a cause for despair. It’s not as bad as it looks because you don’t always need to use all of the parts.

    That’s why so much of this article discusses how these parts work together. The point is to empower you to make your own decisions. Use this knowledge to decide which parts you need to use and when. In this way, you too will have a fast WordPress website.

    slots empire bonus codes
 Editorial (ms, al, il)

    This article has first been published on .

    Fonts by Latinotype.