 Welcome everybody, my name is Scott Mitchell and here we have a talk on managing Drupal with Nginx. Specifically, this is going to be performance of Nginx hybrid versus a regular Pure Apache setup. You guys enjoyed Nginx Drupal Con so far, I guess it was awesome, right? Every time I come to one of these, it just gets better and better, so it's pretty awesome. You guys can follow along if you have the Wi-Fi. That's at inmotionhosting.com, slash support, slash Drupal Con, north of capital D, capital C, slash 2015. It should be exactly the same as I have here. This is local copy, no variables to mess up there. All right, a little bit about me, again, my name is Scott Mitchell. We're working with the web on and off, or mostly on since 1997, basically started by deconstructing homepages and figuring out HTML like that, learn some pro. I was already a programmer, just nothing web-based, so that's how I get my start. Since then, I've been working on and off with various different technologies. I've been with my company in motion hosting since 2010, so it's just five years there. I'm a customer community developer, and while I'm not a full-time coder, we do develop some tools to help both our customers internally and externally, but what we specifically do is, as a customer community, we help the global customer, which is not necessarily our own. But anybody that has questions on the web about Drupal or any CMS they're using, set up. So we field questions from all over. The only thing we can't really specifically address is the customized set up of servers. But we do get a lot of questions from everywhere, whether it's a WAMP set up at home, or even from other competitors or whatever. I've been working with Drupal since 2012. Not really a lot. Not really a super deep experience there, but since version six, mostly seven, because that's where most of our customers are based, and we're starting to reach into eight as that goes along. Okay, now I know you guys, it's 5 p.m. We have an hour block, and you guys want to eat, so it probably won't take the whole hour, so I'll do the best. Even if that Starbucks hasn't worn off, it'll probably be pretty quick. So we'll see how that works out. That's what we have going on here next. All right, so about in motion, we've been around since 2001, so working on 15 years here. And our focus is small to medium-sized business hosting. So if you have doctors or lawyers, whatever they have, more of the business card type websites who work with those, we have a lot of mom-pop style e-commerce businesses, whether they're running their own little Etsy projects or a little bigger, whether they're reselling some things. A guy that cuts my grass down the street, the kid, he has his own website, so pretty much everybody has websites, and we focus mostly on those guys. We do have some enterprise levels, some commercial class level, but we're another more of the outliers than the main. You can find us at inmotionhosting.com, and our specific department, my specific department, is inmotionhosting.com slash support. So if you get home later on, you find you have any questions about this, about Drupal, or anything else in general, no server configuration, but anything else, just hit us up. It's more of a forum style where you ask a question, and we come back to you. And you can follow us, of course, on Twitter at inmotionhosting. All right, so a little about this project before we get to the agenda. It was more of a theory for us. We hadn't really done this yet. We knew about setting up a hybrid system from reading what other people have done it. And so we kind of wanted to see what would happen if we took basically a Joe average site and performed this test on it and see what kind of performance increase we would get and what that could mean to our customers or anybody that might be in the same situation, because it wouldn't help everybody. We didn't fine-tune Apache Engine X. We kind of just jumped in there with it, and this is like the only big change we made. Okay, so there wasn't a lot of back-end configuration, because we wanted to see what happened just purely on this one instance. All right, so we did normal site, and this is a C-panel-only setup, because the plug-in we used is working for C-panel, working with C-panel. So this is something that works with hosts that have the C-panel setup. No hosts don't work that way, but don't really have data for that side. All right, so the agenda here, we have first a quick history of Apache and Engine X. These are kind of a brief history just to show where the state of the web was at the time and kind of background of why they were written. And then we have Apache versus Engine X, and that's not a comparison to say who's more dominant, the different features they have and the ones we want to try to optimize in this hybrid model. So this is a test setup, just a basic rundown of our specs and the site and the server, and then of course the results of Apache. All right, so you want to jump in Mr. Peabody here in the Wayback machine and go to 1995, and dominant server at the time, HTTP server was the NCSA written by Mr. Robert McCool, what's that name, McCool, which I had a name like that, Microsoft also kind of jumped on the market there, IIS 1.0 in August came out with NT 3.51, it was packaged with, so they were entering the fray there. Apache actually started development in early 1995, it was basically built off of the NCSA model, the project that ended and Mr. McCool had left the project, so people were kind of picking it up and working with it from there, which gave it a quick release date here of December, so you're looking probably April, Mayish, and then moving forward to December, they released, this is kind of what it looked like with the HTTP server saturation, I guess you could call it, NCSA here, topping out 52%, Apache at 5%, that's basically release month, but you know, people that were kind of involved in the project knew what was going on, and these are people that are kind of coming off the NCSA and just kind of early adopters, so I was in there with 5% and Microsoft, they had just jumped in in August, they had just less than 1%, so shoot forward six months, 1996 June, Apache's already dominating at 33% with the NCSA running at 22, now on the previous slide we showed the two combined ran about 57% total, and here they have 55%, so largely it was just Apache taking over the NCSA share there, Sun of course jumped up a little bit, Microsoft growing, nice 3% there, and the other guys hanging out at 26, so websites of the 90s weren't exactly what they are today, if you remember these, this site's actually still up on the web somewhere, they were very bland, they didn't have a lot to worry about, there wasn't the interactivity that there is now, you know, videos were rare, you can see this is normal site, very bland, very static pictures there, not even really any columns going on, most formatting was tabular, so real easy, not much to worry about, and the most acting there, the social media was not big, of course, but everybody had a home page, you guys remember Angel City, Angel Fire, Geocities, those kind of things, and I guess the most active you got at the time was the spinning icons, the animated gifts, you guys remember those, and one more famous ones, the hamster dance, you guys remember that one, anybody, no, there you go, couldn't make them dance, sorry, but you know, still wasn't a lot going on, very easy page, so more recent history though, 2005 we had Apache Peak at approximately 70% of the market share, now imagine how much the web grew from 1996 to 2005, now back then, big players would just get on the market, but now everybody, like I said, everybody has a website, and so they had the 57% or so back in 1996, they took that over to 70%, plus all the growth since then, so they were definitely a dominant force, but you can see now, 2015 they're down to approximately 39, which is the lowest since 96, it's not because they're bad, it's just because now everybody needs to configure to their own specific niche, and so there's other options out there now, all right, so NGINX, we traded the way back machine for a DeLorean, so we started development here in 2002 by Mr. Igor Sosoyev, you said that right, from Kazakhstan, and he started from scratch, so a little bit longer development time there, and we released in 2004, and one of the things that was created is to handle the C10K issue, now this is for having 10,000 concurrent connections on your site at one time, I don't know what that would do to my site, but you know, a lot of sites, they were looking forward to that, might crash a lot of people's sites, now even if they have, especially if they have a e-commerce site, so that's one of the things they want to look at, and they wanted to handle a lot of traffic, so high traffic sites like Rambler, which is a Russian search engine, anybody heard of that before, one that got it, I never heard of it before either, so 500 million requests per day in 2008, pretty nice, half a billion, by comparison, at the same time, Google was doing 1.6 billion searches a day, but it's Google, they have their own setup, and now they're doing 3.5, so, but so he was looking to fill the needs of sites like this, all right, so three years after release, Apache is still dominating at 50% percent, and Microsoft now at 32, so together, putting out probably almost 90%, 88% there, Sun is shrunk back down to two, pretty much on their way out, and Google popped up there at 2%, so three years after release, EngineX has new, under 1%, just trying to get noticed out here, Google website, yeah, they don't use it commercially, but I'm not sure what their goal is with that, they're out there, still run around 2% now, this is more recent data now, so four to eight years, Apache at 39%, Microsoft 29%, you see a slight decrease there, but EngineX up to 15%, now over eight years it seemed like a great huge leap, but the big story there is at the top 1,000 sites on the web, the top 1,000 busiest sites, they are the dominant server, so they are kind of finding their niche there, doesn't mean Apache is bad, just does things differently, so I'm trying to knock Apache at all, all right, so sample sites, so we have top 1,000 sites, and what kind of sites really is that, three of my favorites, Netflix, anybody have a Netflix account, most of you, in my circle it's like having a cell phone if you don't have one, kind of out of the loop, so my go-to for movies, I'm too lazy to go to the shelf and open the box, so I just turn on the Netflix, Hulu, anybody, it's my go-to TV spot, so with these two, I think it's cable, but they run, they're front end there, off of the EngineX, and then Pinterest, all right, how many guys have Pinterest? I'm the only one, no, that's like four, but okay, there you go, don't knock it, it's full, my boards are full of food I will never eat, and projects I will probably never start, but I like to look at them and dream one day, but three real-world examples, these guys run EngineX, and doing quite well on it, all right, so Apache versus EngineX, again, it's not a who's better, but it's more a comparison of features, I'm staying pretty high level here, all right, so connections, how does Apache handle these connections? Well, it uses NPM, multiprocessor modules, ours specifically uses the worker, and it spawns these processes, all right, and each process can handle multiple threads, each thread has a single connection, so it's kind of dedicated that one connection, EngineX is a little different, it does spawn workers, and each worker handles thousands of connections, it uses a fast looping mechanism that checks events, and they're processed, and then once they're handled, it's removed from the loop, what does that really mean? So basically, if you're a worker, if this room was in the worker, and everybody in here was a connection, you had something you need to be worked on, you need to spawn an event, basically you would raise your hand. Okay, it runs through everybody that has their hand raised, grabs through and handles the process, and once that's done, the hand goes back down. So everybody without their hand raised, it's kind of ignored, but just, you know, you're glossed over because you're not needed, because it's kind of how that works. So if everybody raised their hand at one time, there may be a problem, it's not only not the case, but so the static and dynamic content, and Apache on its core level there handles it by default, which is great, and passes the dynamic content over to a processor embedded to the worker instance, ours uses mod suphp, because we use the MPM worker, mod PHP, also another one, and swaps modules that are now as needed for the requirements, it's like library toolbox over here, and next also handles a static by default, and it's a really good setting, really fast. But the dynamic content, it passes to an external processor, fast CGI here, because in a pure engineered environment, that's pretty much the go to spot it, it basically outsources it completely. And that leaves the overhead only for a static content, which makes it more efficient. Go to configuration here. So Apache has a distributed configuration via HT access files, and love them or hate them. They're pretty nice. Now the problem is it checks each component in the path for an HT access file. So if everybody in here was a component directory, you have the opportunity to have an HT access file. Apache itself has its main configuration file, but as a directory or component, you can modify or change these rules through HT access file. Apache has to ask each and every component, whether it has a rule change has a chance as file. So that can take some time, especially if it gets bigger and bigger. You have small number, not so much, but as it gets larger, and you see how many files and folders in some of these CMSs, typically, though, they're used for URL rewrites, access, rejection, authentication, like that pretty URLs. Engine X, on the other hand, has no decentralized configuration. So it doesn't have to go around and ask everybody. This doesn't mean that it can't do the same things. It just doesn't it's different. But because it doesn't have to go around and ask each component, do you have an HT access file? Do you have a rule change? Do you? Do you? Do you? Then it makes things a little faster. So it increases performance. It's also better security because only the admins, the admin can figure this. So you don't have to worry about too many people having their hands in the security department. However, Apache can turn that off. So if you have a concern with that about the security issue, you can turn it off in Apache. Apache uses modules kind of like Drupal. So you can go in and enable, disable, and you can turn them on, turn them off. You have something you need to use, turn it on. It's great. If you're done with something, turn it off. Engine X doesn't do that. So the modules are compiled into the core. So every time it has to add a new function with a module or remove a function, if you're going to recompile it. Okay, so that's the run down there. So what does an Apache Engine X hybrid look like? Other than ugly? I don't want to use Engine X in front here. It's reverse proxy. That's what you want. It's going to handle all the client requests. It's kind of like the receptionist knows where to place things, tells things where to go. When you use our speed here, it's serving the static content. So your CSS, your JavaScript, your images, your HTML. And we want to pass the dynamic content off to Apache. It has to outsource it anyway. So we want Apache to do its job over there. Now we could use, like I said, the C is fast, C is giant, just do it, you know, straight engine X. But we want this to be easy to install. So anybody here wants to do this at night, at night or get back home, someone do it, want it to be very quick and easy to do without having to reconfigure a bunch of stuff on your server, which makes easier configuration for content management systems. Drupal specifically, because we're talking about that here. So when you create your install, your Drupal creates a CIACS file and has all the, you know, configuration there. It's got your URLs turned on and everything. So if you add this engine X in here, you don't have to change that. You don't have to set the configuration to work with engine X. And no need to change hosting companies in most cases. Most cases mean if you're with a shared host, and that's all they have, this probably isn't going to work for you. You're going to need a VPS dedicated server, root access to do this. So in those cases, you might need to change. But if you're in a host that has all three of those, or at least VPS and dedicated, you can certainly do this. And the idea is, if you're on the cusp of having to, let's see, change, if the system port system or system admins are trying to urge you to possibly upgrade, change hosts, whatever, this can hopefully buy you some time. So ultimately, though, pretty much if you like your host, you should be able to stay with your host. So the test itself, we ran Apache Bench benchmarking tool. And that's what gave us our data here. And the data itself, like I said, we ran for speed. Wanted to see what's going on. We'll touch other things, a couple other things in addition to that. And we vary the concurrent users between 100 to 150 and 250. So just like 100, 150, 250 people visiting your site simultaneously. We also vary the request for 2500, 5000, 10,000 requests. Again, we're trying to stay pretty normal. We first started to do it with two different servers. But then we went, we didn't want any configuration or hardware differences or anomalies to play any part in this. So we stayed with the same physical server, which is, you know, standard VPS with us. And that's run in SSD, 8 gigs of RAM, my server, basically. And we ran a Drupal 7 test site. Again, we've worked mostly with Drupal 7. So we wanted to stay with what most of our customers use. We basically, we didn't need to a hello world site. You can run anything on the hello world site that's gonna work. So we built a recipe site, about 10,000 or so recipes on it and gave it a theme. We put the, you know, your panels, your views, your chaos tools, all that kind of stuff in there. It's normal Drupal stuff, add a few other modules. Let's say a theme, we change the theme, just make it a nice little site. But nothing e-commerce or anything like that, but just kind of a normal, everyday kind of site you're running against. Now this is the plugin we used, engine xcp. If you can read that, you can find it at enginexcp.com. And it's free. That's one thing we picked. Again, we want everybody to be able to do this. We want this to be very easy for everyone. And sometimes cost is a factor. So free was the one of the reasons my partner, he's not here today, helped us pick this thing. The DDoS protection is really largely because of the engine x, the way it handles HTTP request. So that's helpful. These are listed as features on the website as well. So it does have a WHM interface, which makes it easy if you're using the Apache, I'm sorry, C panel setup. Works for GC compression. And C panel service monitor support, so no need to specifically turn it on or off. Individually. PHP write compatible. And you can manage which domain uses engine x, which domain uses Apache via SSH. Again, that's engine xcp if you guys are interested. Okay, and the installation's super easy. I'm not sure how technical most of you guys are. On the back inside of things. This is literally everything we needed to do. Seven steps. You don't have to know what the code means, but just real quick, I'll run it. It's easy. We just change directory. Then we grab the file, open it up, change to a new directory, run the install, add executable permissions, and then activate it. Our customer specifically will have a little bit shorter, because we took the first five and made it into our own script, which is compressed into one. So we can really do it in three steps. The uninstall is basically just as simple, but you can also just turn it on and off. So something you can try, test it, if you like it great, you can keep it if not, you can go right back to where you were without having to worry about anything. Let's come over a little before there. Alright, so first results. Apache kind of supported us in this. I'll show you how it works. But we had a hundred users, and we weren't like, we were going for speed. And the 2500 request process here in 26.5 seconds. 150, shout out to 41.3. But sadly, 250 did not finish. We had to configure the Apache to hold 250. But it got pretty close, but just died out before it finished the 2500. And sadly, you're going to see that occur to the rest of the Apache. The engine is hybrid, which is literally just laying right on top of it. We had some speedy stuff going on here, 100 at 9.5 seconds. And that was pretty, as fast as I was expecting, to be honest with you. And then we ran several instances of this. So it wasn't, they weren't always exactly the same. This is one example, but they were fairly consistent in how it worked out. With the 150 up to 19.7, and the 250 slightly, slightly faster, but it did complete, which was a good thing. So what you can show here is that engine X obviously had a lot faster time processing these guys. Whereas Apache did do the first two. They both had the same kind of arc at first, first two. And I'm not sure what the Apache would look like at 250, but I see kind of level off there. They do work within a range. So sometimes we ran them, they looked a little bit differently, but they still pretty much fell within the same range. A few milliseconds, I'm sorry. So test two, we ran with 5,000 requests. And the Apache ran 44.8 with 100, and then 47.9 with 150. Again, with the 2500, 250, I'm sorry, it did not finish the hybrid, the slain on top fit, ran here at 33.8 seconds per 100 users, 36.1 for 150, and then actually faster with 250. I don't know why. We ran this a few times, and it occasionally happened this way. We were happy with it. So again, you can see the same thing. You know, there's a big disparity there between the engine X and the Apache handling as a request. And again, it's a range, so the curve is not really a big concern, but we did run it a few times and kind of saw the same thing going on. So we went for 10,000. Alright, 100 users were in 10,000 requests. We got 111 here, 0.3 with Apache. 150 users, we had 104, so it went down a little bit, still within that range kind of thing. And then again, 250 just died out on us. But the hybrid was quicker here, with 100 users at 68.5, 150 users at 64.8 faster, and then 250 at 76.1. This gave us a nice little start. The interesting thing is they both dipped from 1 to 150. We're wondering about that. It's got your heads, but it was consistent. And again, you see the same thing, where the difference between engine X, hybrid, and the Apache. And it maintained its... So the rilts here, we had 2,500 tests. The hybrid was twice as fast as the Apache. We weren't really expecting that. We were expecting more in a third, maybe 35% range, like we got for the 5,000 tests. It was consistent there with 35% faster, and then the 10,000 tests came in also at 35 to 40% faster than Apache. Plus, the hybrid was able to process all the concurrent user levels versus Apache dying out with the 250. Alright, so what does this all mean? The increase in overall performance was gained by layering the engine X on top of it. Okay, definitely able to handle a higher level of traffic. So if you have a site that may be getting some kind of local media attention, or you have a client maybe gets local media attention, radio plug, maybe local news, they get mentioned on the Oprah's plug and crash it, but we've seen that before, but still might hold it a little bit longer before it crashes. So that'll help. It's really easy to toggle on and off, so you don't have to worry too much about, you know, if I set this up and it doesn't work the way I want it to or doesn't perform for you the way it did for us, you know, do I have to go through a whole mess to turn it off? No, it's not the case here. No need to reconfigure Drupal, which is always nice. Any time you move a site, even from one, you know, Apache server to another, you guys understand that can be a pain anyway. So no need to reconfigure Drupal to work with this plug-in. I just kind of set it and forget, kind of plug right in, plug and play basically. All right, you may save some time and money by increasing the time before you upgrade a server. Like I said, this is something we want to test for our customers. We have a few, a few main certain percentage of them that are always kind of right in that line and they call in when they kind of hit the limits. And definitely upgrading is one of their options. But, you know, if you don't have the money yet or just kind of want to optimize yourself a little bit, this can definitely save you three, six, maybe 12 months of time before we have to increase or I have to upgrade. Now there was some concern from our system admins when we were in this test about memory. Nginx was going to be faster, but was it going to cause any memory problems? And we saw, this is, we had an 8 gig server there. What doing a test that we had, we maxed out about three gigs. So not too bad. It did go up, probably doubled the RAM that we were using with the Apache, but it was still well within the VPS limits. So it wasn't a concern of overloading the node or overloading that particular container and causing issues again with the system admin, because that's kind of what we're trying to avoid all together. And as far as the number of requests that processed, that didn't process, they was pretty consistent between both. So we didn't really list that, because they were very consistent. But Starbucks was still kicking, I guess. That was it. But you guys have any questions on that? It's just from, like I said, a high level test to see what's going on. We're going to do more tests with different aspects of hybrid versions for our customers as well. So it's an application that's very intense in the configuration in Apache. Right, no, it's going to work off, because it's passing down to Apache. So Apache's still going to run and do the dynamic stuff, run all the rewrite, state access files and everything just like it normally does. InginX CEP is a, yeah, it's a plugin for a C panel that puts InginX in the front. So InginX grabs all the stuff coming in first, and it sort of runs a static content and then passes the other stuff down to Apache. So Apache, remember in the first part I talked about InginX running and it passes things, it out sources out to say fast CGI. So InginX is in the front and it grabs, you know, all the static content as it comes in. And then anything left over, which is like the dynamic stuff, and it passes down to Apache. So Apache doesn't even really see it. I'm in the back, I'm sorry. Not that we saw. We just, we just installed it straight with the, like said, it's a real default kind of installation for Apache. We didn't have to increase configuration or change it really for Apache. It gave, right, had like the 200 codes I guess we would say and the non-200 codes. We did, those were consistent among both of them. That was speed, yes. Yeah, exactly. We didn't test that. That's probably one of our future tests. We do want to test that. This one was specifically because we run Apache as far as we host and we don't have a lot of InginX customers, pure InginX customers. So this is like a first step for a lot of these guys and we definitely want to test that and see how it runs just with pure InginX and get that as an option to our customers as well. Because we have a lot of people that do ask for it. So, but this is the first step for those that maybe aren't looking to completely reconfigure or completely do another thing yet and just buy them some time at least until they can, until they can come up with either an upgrade or by this time we might have the other option out for them. We didn't use that. There's actually a reason for that. My partner told me. But as far as like, this is our standard configuration. So we went ahead, because we use Worker. There's actually a couple of technical reasons we use Worker over Event. It's off the top of my head right now. I don't know. But right, right. And to be honest with you, I don't think we're running too far right now. And that's probably the biggest reason. But Worker, I think, is a little more, oh, with, we use Worker because of the, which has to use two PHP. But because of our DSO option, that's why we use Worker versus the Prefork. But as far as the Event, we haven't tested the Event yet. We didn't. We just ran it straight. Like, you know, that could do. That could very well come to a lot of it. Again, we just try to create what normal customers are going to run with. And a lot of them, for some reason, don't want us to, or they want the server side to be as quick as possible before they implement the caching kind of thing. So we're trying to go with their requests and say, okay, what can we do for them first? Even though this seems like it might be a little bit more involved in turning on caching. But a lot of them like maybe it's a crock-pot kind of thing, kind of set it and forget it kind of thing. And if we can help them get this, or even do it for them, then that helps them out. Then the caching is definitely involved. We just didn't want to run. We do want to do all these different tests and put those results out as well. That's definitely, definitely in the works, just for this particular way to do that. You could. I don't actually know. That's unlike a check-in too. Definitely, if I gave you information, I can definitely check into that. And I want to put it all into the test. Yeah, test results as well. I'll definitely check into that. We will, I do want to post all the different data that we did and put up here, because like I said, this was just more concerned at the speed level with the memory issues I mentioned, and the consistency of the non-return codes or the non-return successes. But I do want to put all that out there. So I will check into that too and put that up there as well. And we didn't run against Farnish yet. We wanted to, again, just another test we haven't run yet. But it's definitely another thing because we wanted to test all the different options here. And Varnish is definitely one of the options. The thing with the Varnish is, as far as their VPS does go, it's definitely going to really work against the memory of the module of the node. So we want to wait to do Varnish as a second step maybe, because it really increases the memory usage. Yes. It seems to. I mean, it doesn't have a problem with running everything. Any configuration changes we made, it worked through the Drupal. If we added the different URLs and rewrites or something like that of the particular authentication, then things seem to handle that pretty well. We did not try that out. That's definitely something we probably should try there. Say again. Right. We will, yeah, that's another thing we can put in there as well. You guys ready? I appreciate you guys coming out.