This post is adapted from a webinar hosted on January 20th, 2016 by Floyd Smith and Faisal Memon. Watch a replay of the presentation here.
Table of Contents
0:00 Introduction
2:30 Your Questions
5:45 What’s New in Drupal 8
7:33 Planning Your Site Architecure
11:13 Replacing Your Web Server
15:08 NGINX Configuration for Drupal 8
16:30 Change #1: Accomodating update.php
19:38 Change #2: Non-greedy Match
20:57 Change #3: Default Location
0:00 Introduction
Floyd Smith: Thank you very much for joining us. Today we’re going to be talking about maximizing the performance of Drupal 8 using NGINX.
Recently we did a blog post on this topic, and found quite a few people are using Drupal 8 and NGINX together. You can find a fair amount of information from us and other sources just by typing some words that look like this webinar title into Google, which we’re very happy about. We’ve tried to pull together some of the best and most relevant information.
But it’s not just a matter of details, it’s also a matter of perspective. Technically, this slide title is a misnomer, because nothing we talk about here actually changes the performance of Drupal itself. Drupal 8 does what it does. What we do here is use NGINX to offload Drupal, allowing it to perform better. Among other optimizations, ww will help you set up to run several servers running Drupal in parallel handling all of your traffic.
There’s an old saying, “Watch out what you wish for, you might get it.” And that’s really true with Drupal 8, and all the other PHP-based frameworks when used for busy sites. If you’re launching a small blog for your friends, you’re probably never going to have a problem with Drupal performance, because the pages will get generated and served as people log in and use your blog.
But when you’re using Drupal the way it’s more and more intended, for very complex web applications, if they start getting busy and have a lot of site-to-site traffic where they’re talking to other servers and talking to backend databases as well as to the actual user, it’s very easy for Drupal’s performance to max out, and without NGINX, that can be a devilishly hard problem to solve.
But with NGINX and a little fresh perspective, it’s actually fairly easy once you get over a hump. That’s what we’re here for today, to look at your Drupal setup with a different perspective and get the most performance out of it. Some of you may already be on this, and you’re interested in details of how to maximize Drupal performance when you’ve already got NGINX up and running. We’re happy to address that too.
2:30 Your Questions
I’m Floyd Smith. I’m Technical Marketing Writer for NGINX, and I’m the author of our new blog post, 8 Tips for Drupal 8 Performance. For the blog posts and this presentation today, I’m working with Faisal Memon. Faisal’s a great technical source and I’m good at identifying what the problems are, rounding up the solutions, and putting them all together.
Together, we’ll be talking about what’s new in Drupal 8, how you can implement a high-performance site, and how NGINX and NGINX Plus can help you with that.
Let me first address the differences between NGINX and NGINX Plus. NGINX is open-source web server software that’s extremely popular. It’s used by more than 140 million websites. You can think of it as the higher-performance alternative to Apache. Configuration is different between NGINX and Apache, and that’s the reason that people usually don’t switch to NGINX until they have a performance issue. But those that learn NGINX often end up using it with everything because it works great.
If you look at the 8 Tips blog post, there’s a link to a book chapter that explains how NGINX was architected, how it’s different, and why it can have literally orders of magnitude greater performance than Apache. This is not a knock on Apache, it’s just a performance difference. Apache was written to be easy-to-use, easy-to-configure, and very understandable, whereas NGINX was written to serve thousands and thousands of people at the same time without even a hiccup. And then, if you ever get to where NGINX is overloaded, you can just put up some more application servers running NGINX. It’s designed for massive scalability.
NGINX Plus is the commercial product. We charge what we consider a small amount for it. It includes support and access to our people here. With NGINX Plus, we offer it to you pre-built rather than just giving you the source code for you to compile yourself. We compile it for you. Even though it’s pre-compiled, we have modules that run on NGINX Plus, so it’s fully extensible.
With NGINX Plus we also have a few additional features for load balancing as well as monitoring and management of your site when you have multiple servers. Faisal will mention a couple of these things as we get into them, but usually we just talk about NGINX, meaning both versions of the software, and then point out the things that are NGINX Plus-specific.
If you’re new to NGINX it’s a great time-saver to start with NGINX Plus, because the support can save you many hours of your time, and you have extra features to help you do an optimal implementation right off the bat.
5:45 What’s New in Drupal 8
There are significant improvements for mobile. There’s full support for mobile site templates, and you can now actually administer Drupal from your smartphone, pretty impressive.
Drupal 8 uncouples the data and the presentation layer, and that’s a good step for performance, among other things. The API is now fully RESTful which makes it easier to use with tools like Angular.js, Ember.js; tools that currently exist and ones that are yet to be invented. The Drupal world is growing and the complexity of sites is growing, and the tools that you can use to support that are growing.
Drupal 8 also builds in better support for PHP frameworks and tools that help tame PHP a bit and make it better-behaved in high-performance situations, make it a little more predictable, a little more standardized. Along these lines, Drupal 8 has built in support for Symfony, an object-oriented PHP framework, and Twig, a library and template engine. These are designed to help you tame and evolve PHP into the future.
There’s also a number of security improvements with Drupal 8. NGINX is a great tool to use to increase your site’s security and there’s a lot to talk about there. However most of our security features are not Drupal 8-specific so we’re not going into it today. But if you do use NGINX with your Drupal deployment, you can rest assured there’s a lot you can do on both sides to make your site more secure.
7:33 Planning Your Site Architecure
So how should you plan your site architecture? This is a common issue faced by our customers and friends.
Evaluate Current Architecture
People are used to the idea of having a web server running Apache usually, and also running Drupal or WordPress, another PHP-based application, or any number of other applications that aren’t based on PHP. It’s a pretty simple model where the application server and the web server are all on one machine, and you can get a pretty high-performance machine, but there’s a lot of potential performance problems.
You can try running your database on a separate server for higher performance, but you’re still asking the application server to do a lot, especially if the same box is also running your web server. And when performance issues come up, it’s very hard to fix them just by throwing more hardware at it — past a certain, pretty low point.
In this kind of architecture, when you’re doubling the use of your site every couple of months, you will quickly get into a place that you can’t get out of by increasing the size of your server or trying to simplify or tune your application, and that’s where NGINX comes in.
Consider Your Goals
So, evaluate your current site traffic and performance and then see what your goals are for future growth. Many people don’t know enough technically to fix performance problems that come up, and then they’re really stuck. Say you’re heading into the holiday season with an e-commerce site. You don’t have time to suddenly learn a bunch of stuff. That’s part of the reason for starting to use NGINX early on in your site’s life so that you’ve got everything humming and easily scalable when you need it.
Running NGINX for one site can also help you tool yourself up for other sites and other things that you might want to do as well. These days we’re seeing more of that preventative or forward-looking use of NGINX.
Estimate the Impact of Changes
Look at what you’re going to be needing now and in the future and consider the capabilities of NGINX and NGINX Plus, both of which will be covered by Faisal. There’s the ability to be a web server, reverse proxy server, load balancer, and also the ability to terminate TLS/SSL and HTTP/2 and a lot of other growth capabilities that are possible with NGINX and NGINX Plus.
Factor in the Cloud
Then look at your likely speed of growth, so you can be be ready for it, and take the steps you need to get out in front of it, and then factor in the cloud. More and more of the web is moving to the cloud. Amazon Web Services is the best known service that’s hugely popular. VMWare is the leader in private cloud.
Many sites now are growing into the cloud, which is where you run the site primarily on the servers that you’ve already bought and paid for, you’re not going to throw them out. But when you get more traffic than those servers can handle, you enlist some servers that are in the cloud. This way, you only have to pay for the instances that you’re using while you’re using them, and you only pay for them when you’re actually running a lot of traffic that would otherwise be causing performance issues for your customers. That’s a brilliant strategy, and we have specific NGINX configurations to take advantage of that.
So have some conversations and think through all those things. It’s wise to do this planning before you run into problems, because then you’ll have a strategy ready for what you want to do and how you want to expand.
11:13 Replacing Your Web Server
The simplest thing you can do to improve the performance of your Drupal site is replace your web server. By replacing Apache with open source NGINX, or NGINX Plus, you can immediately increase the performance of your site.
This doesn’t actually directly change what Drupal is doing. What it does is it takes Apache, a web server that tends to get overloaded with too much traffic, and replaces it with NGINX, which handles lots of traffic very well. Now, how does NGINX do that? The details are in the way that each of them works.
Apache spins up a separate process, a separate thread for each new connection that it gets. That takes time, and very importantly it uses memory. What tends to happen is that as you get more and more users over time, or if your site suddenly becomes more popular, such as when you head into the holidays or another busy period, your server’s physical memory gets overloaded and it starts swapping the disk. That’s just deadly, because the second that you start swapping to disk, everything slows down.
If you get more users on top of that, more and more of them go to disk, everything slows down even more. And although you may still be serving all these users, the perceived performance of your site suffers. People start clicking away from a slow web page. They start doing something else. They say, “I’ll come back later.” They probably don’t. So, it’s just a depressing mess.
You can get more physical memory, but that’s expensive and limited. So, that’s where NGINX comes in. NGINX runs on an event loop so it doesn’t assign memory to each connection, it just handles requests as they come in from however many connections there are. It was designed this way to solve the C10k problem, which is handling 10,000 or more simultaneous connections.
So, if your site is getting seized with Apache, then replacing your web server software with open source NGINX or NGINX Plus is a huge immediate help. It also enables other performance boosting capabilities that Faisal will be going into. For example, once you put NGINX in, even just as a web server replacement on the same box that runs Drupal, you can immediately start using NGINX caching capabilities. There’s a few different types of caching you can do which are extremely effective for Drupal. And from there it’s easy to step up to using NGINX as a reverse proxy server, on a separate box.
Once you have NGINX set up as a reverse proxy server, the Drupal machine can now focus solely on running Drupal, which is huge. NGINX is handling all the internet traffic, it’s doing caching. Now a lot of requests don’t even have to go to the server that Drupal is running on, so performance increases significantly.
If you also, or separately, use NGINX as a reverse proxy server, in front of your Drupal machine, you can also add additional Drupal servers and load balance them to make sure the user gets a consistent experience in their session. We’ve been doing that for a long time and we’re quite good at it and you’ll get quite good at this as well.
So, the first step in improving performance for your Drupal site is simply replacing your web server with NGINX. And once you’re there you get many more options.
Now we’re getting to Drupal itself. We’re going to start with Drupal 8 configuration, which Faisal will explain.
15:08 NGINX Configuration for Drupal 8
Faisal Memon: Hey, thanks a lot Floyd. My name is Faisal Memon and I do Product Marketing here at NGINX. I’m going to take you through some of the specifics around Drupal and NGINX, starting with the configuration.
The changes needed for NGINX to support Drupal 8 are mostly minor. They’re mostly related to the update.php front controller. On our wiki site we have a sample configuration available, a full NGINX configuration that you can use. If you don’t have a complicated Drupal site you may actually be able to use it straight up. If your Drupal configuration is a little more complex you can use bits and pieces of our configuration.
Let’s step through some of the changes in the configuration we’ve made for Drupal 8 compared with the configuration that we’ve provided for Drupal 7.
16:30 Change #1: Accomodating update.php
First and foremost is accommodating the update.php front controller.
If you’re using the previous configurations you would encounter a problem when you have a URL like /update.php/selection.
The location block on the left side is the main location block in the NGINX configuration that will go ahead and execute the PHP scripts using PHP-FPM. In this particular location block, the regex has a dollar symbol at the end, which means it’s not going to match on anything that has a slash or any sort of directory after the PHP script. So, this particular URL /update.php/selection will not match on our Drupal 8 URL. The PHP script will not be run, and NGINX will return a 404 error instead.
In the location block on the right side, we’ve put an ‘or’ within the regex. We still have the original regex in there to match the Drupal and PHP scripts that we’re running before. What we’ve added now, after the ‘or’, is the URI portion which begins with update.php, so we’re going to go ahead and match that as well. You’ll notice that we don’t have a dollar symbol at the end of the update.php, so we’ll take in all of the stuff that comes in after it, match, and run the PHP script with that.
There’s another alternative that you can use. The example in the upper right location block is very, very strict in that it will only match update.php. This less strict version that’s further down will match any PHP script that has a path after it. This is more of a forward looking solution so you won’t have to make any changes for Drupal 9, Drupal 10, or whatever comes in the future, if it has URI syntax similar to what’s with the update.php.
The downside of using the less strict version is that it might break legacy Drupal URIs like /blog/index.php/legacy. That will now match and will not work as it did before. So the trade-off is to either be more future-proof or have better support for legacy Drupal URIs.
19:38 Change #2: Non-greedy Match
The second major change is just the next line in the NGINX configuration after that. After our location is the fastcgi_split_path_info, which splits up the PHP URI into the actual script name and the stuff after the script. The change here is to accommodate URIs such as the one that I've listed here, which has .php listed twice. The old version on the left is a greedy match which is going to match the entire URI up to the second “.php” and try to run that -- try to call out with that as a script name and it's obviously going to be not found.
So for the Drupal 8 version on the right side we just add a little question mark, which makes the script non-greedy. Now it'll match just the first .php and use that as the script's filename. And then the second half, the second core/authorize.php will passed on as well.
20:57 Change #3: Default Location
This third change is in this other location block. This also applies to Drupal 7 but I just wanted to mention it for people moving from an older version of Drupal up to Drupal 8.
With the older configuration, we would send it to a rewrite block which rewrites the URI, and in the newer version on the right side we're calling out to index.php with a query string. The older version, the one of the left, can cause the query string to be altered which can cause that functionality to be broken.
Those are the three major changes moving from older versions of Drupal to Drupal 8 that you'll need to have within your NGINX configuration. On the NGINX wiki we have a page specific to Drupal, and within that page we have a sample NGINX configuration that you can use with Drupal which encapsulates all the information that I've presented.
This blog post is the first of two parts on maximizing Drupal 8 performance with NGINX, and is focused on site architecture and NGINX configuration. The blog post based on the second part of the talk, focused on caching and using NGINX as a reverse proxy server, is coming soon. You can watch a replay of the full webinar these posts are based on here.
The post Maximizing Drupal 8 Performance with NGINX – Part I: Architecture and Configuration appeared first on NGINX.
Source: nginx
