 My name is Nick Rosenthal, I'm a developer, I also maintain servers, I'm a front-end developer, so I do a bunch of things. Today I'm going to be talking actually about servers and hosting and different setups, what I call a stack. So what's a stack? You've got many dictionary definitions there, we're going to use neither one of those. So to me the stack and what we're going to use the definition as for this session is the components that make up your application. So everything from the web server software, your operating system, all the way to the code. We're going to focus primarily on the web server for this talk and some PHP processing facilities, so we're going to look into that. We're going to look at different types of setups, how they work together. A little bit of performance tuning for Apache only, not for the other versions that we're going to touch on. But I'm going to explain the differences, what each one kind of does. And then towards the end we're actually going to do performance testing on eight different setups. We're going to have a bracket format, we're going to make them fight to death to find which one is the last stack standing. So performance is not just speed, it's also speed and reliability. When you first start coding, you just kind of get your lamp stack going through some little blood pose you found and all of a sudden you're up and running. Or maybe use some shared hosting and you don't have to think twice about it. But as your career progresses and you start writing more complex applications or you start actually getting more traffic, or your clients are getting more traffic, you realize that that initial setup that you were so happy with when you started to learn to code is no longer sufficient. So you start looking at different setups that you can use and improve upon. So let's look at some of those. First, if you run into this issue, maybe your first reaction is to throw more hardware at the problem. Maybe you have a VPS, it's a small little thing that's been working great forever. You get a little traffic, things start lagging, it crashes too often. What do you do? Well, you just upgrade to the next tier, right? Because that's just going to take care of it. That might fix the problem for a little while or patch the problem, but it's not scalable and it can end up costing you a ton. So this should be the last step that you take to add more resources. What you should really do is optimize your code and optimize your stack. In this case, we're going to talk about optimizing your web server. Alright, so the goals for this session. Get a general overview of the different stacks. Hopefully you'll learn something and hopefully you'll have a little fun as well along the way. I just had lunch and it's the second day of the conference, so I hope I don't bore you too much. So we'll look at some common stacks used for PHP. And like I said, then we're going to go through the little tournament style to see the last stack standing. So please, grain of salt here, big grain of salt. I'm only covering basic stuff. The tests that I'm going to run are not scientific and they're not the way you should be determining what the best stack for your project is. But I'm just hoping to give you enough information to get you excited about performance and go and study more and learn more and experiment. Get your hands dirty and hopefully, you know, end up with a better server on your end. Alright, so the setup for everything we're going to do today. It's a one gigabyte server running Ubuntu 14.04 long term support hosted a digital ocean. If you didn't know that setup costs about 10 bucks a month. So it's actually really economic and you'll see that you can get some really great results. So let's dive into all these different stacks that we're talking about. And the most popular by far is the LAMP stack. So who here has run a LAMP stack or runs a LAMP stack? Okay, so pretty much the entire room. So, you know, LAMP stands for Linux, Apache, MySQL and PHP. And the setup can go a long way if used properly. But what makes it so popular, it's also what makes it inadequate in many aspects. And the reason is that it's so easy to set up. On Ubuntu 14.04 and actually in previous versions as well, but the one I'm showing now, you can get a LAMP stack with one command, right? You do, as you do task cell, maybe it'll tell you that task cell is not installed. But let's get past that part. You run task cell. And next you're going to see is, hey, send me up a LAMP server. And after you do that, you're up and running, literally. You can just start hosting a site. So it makes it ridiculously easy, but you can imagine the default setup is not, you know, optimized. So according to the Apache 2.4 documentation, which is the latest version of Apache 2.4, when you install it by default, it should go into what's called the event, MPM. And we're going to get into what MPMs are. Just give it a second. But for Ubuntu 14.04, that's not correct. It'll actually install pre-fort, which is by far the most common way of running Apache. And we'll touch on all that. So anybody know what an MPM is? Awesome, because I'm about to tell you. It's a multi-processing module. What it means is pretty much how you're going to process the PHP. So, or not, sorry. It means other things. So let's say, let me tell you. So in pre-fort MPM, Apache will use multiple child processes with one thread each, and each process handle one connection at a time. So don't get hang out on all those definitions. It's just the way Apache will spawn new processes to serve service new requests. Worker MPM, which is a little more advanced and a lot less used, uses multiple child processes with many threads each, and each thread handles one connection. So less processes, but each process does a lot more. Event MPM is the latest version, and it actually just came about with 2.4. It wasn't available in the previous one. It does the same thing that Worker does, but it also adds some asynchronous processing. It's got a couple of gotchas. If you use SSL on your site, it will fall back to running just like Worker. So you lose all the asynchronous stuff. So just keep that in mind if you're interested in that. So let's dive in now that we know a little bit about these MPMs. And was that clear, or are there any questions about what each one is? Cool. All right, so let's start with the LAMP stack on Apache 2.4 pre-fort. Pre-fort, which was the default installation that we did. And if you're running 2.2, it's definitely the most popular one. And what pre-fort does, actually, it uses Apache itself to process your PHP. So you've seen mod PHP on your Apache installation. If you ever notice that that module is installed, that's what's processing the PHP. So Apache is not only serving the pages, it's also compiling the code. All right? So the main consideration to tune up a pre-fort in Apache 2.4 is the MaxRequestWorkers directive. And we're about to see it, so don't worry about remembering MaxRequestWorkers. So this is the directive that tells the number of processes that will be started to service requests. Because you should limit those if not they would go on infinitely until crashing your server. You don't want to run out of resources. So the formula for figuring out how many MaxRequestWorkers you should use, it's pretty simple. It should be the total memory available divided by the average Apache process size. So let's look at that. Can you guys see the script on there? Cool. So in this case we can see that the average process is about 2.2% of one gig. Right? Which is about 22.5 megs. We want to limit Apache to use half of the available RAM, which is about 512 megabytes. Let me know if I'm losing you with all these. This kind of tells us that we can go with about 23 MaxRequestWorkers. That is, Apache will not go past 23 processes. Just keep in mind that when I took this screenshot, the server was sitting idle. It's a server that I use only for just coming up with the test for this talk. So this has no real traffic. If you're going to monitor your site, do it over an extended period of time. Do it while there's peak traffic, when there's no peak traffic, and really get a good idea of what your average size process is. I'm telling you 22.5 megs, probably pretty low. So just keep that in mind when doing this measurement. But we know that MaxRequestWorkers is 512 megabytes. That's the RAM we want to use, divided by the process size, that gives us the number of MaxRequestWorkers. When you set it up, it looks like this. And this is one of hundreds of options you can set up for Apache. But it's the one that's going to have the most effect. So you're going to get a ton of payoff by tuning this for doing just one little five-minute exercise. So by default, it installs with MaxRequestWorkers at 150. That could potentially use 3.3 gigs of RAM, which is over three times more than we have in this server. You can imagine that will cause either swapping, which you go to disk instead of RAM, makes it a lot slower, or you can just crash your machine altogether. So limiting these numbers is really important, and you can definitely just keep Apache running happily for the server size you have. You get a bigger server, adjust the numbers again. Let's look at LimeStack Apache 2.2 free for it. So this is the same mode as the one we just saw with 2.4, but it's a little bit different to actually tune, so I wanted to show it to you. And also Apache 2.2 is probably the most popular version of Apache out there. It's not something that most people, oh, there's a new version of Apache. Let me run and install this. How exciting. Most people will ignore it altogether. So 2.2 is there to stay for a while. 1.3, which was a previous version, is probably still running many sites. So I wanted to call some attention to it. Because I wanted to keep all the machines the same and I wanted to keep running Ubuntu 14.04, I had to compile Apache and PHP from source to get it installed. If you've never done it, I recommend that you do it once just to get a good appreciation of how much time your package manager, your YAM or your app or whatever else you use, how much time that package manager is saving you. This one installed from scratch. This is what we get. You can see max clients with 150 being the default. I wanted to show you what that looks like. And instead of max request workers on Apache 2.2, it's called max clients. But they're equivalent. They do the same thing. How many processes you're going to spawn. The math we do is the same. But just keep in mind anything above the number of max clients will be queued up. So if you set it too low, you can actually make your site looks low when it's actually just sitting there with idle capacity. So don't just say, well, if I keep it down at five, it's never going to crash because it's true. But when the six requests or seventh requests or eighth requests come in, they're going to be queued up. So you want to use the maximum that does not affect your performance. So let's look at how we're going to tune that up. Average process size, which is in this case roughly 13 megabytes, which is really low. You never see this on a real working site. So always monitor your size at different stages. And even though the math indicates we should set the value to 28 max clients, I went ahead and I cut that out to 14 for this experiment. Because I know 28 is just going to kill this. I mean, I've seen it before. So we're going to keep it down to 14. And this is how we end up setting up the actual stack. You see max clients, which is the second from the bottom, is going to be at 14. All right. So let's get into some more interesting stuff. Stack with Apache 2.4 in worker mode. When you go to worker, Apache no longer processes the PHP for you. It does not compile the PHP, which makes it a lot faster. Because now it only has to do one thing, which is serve pages instead of doing actual processing of the code. So in order to use it in worker mode, you need to install the fast CGI process manager, which is PHP, FPM. So what does it do? Instead of using mod PHP, when a request comes in, it will be forwarded to PHP, FPM. This can happen both as a Unix socket or as a TCP socket, whichever one you choose really doesn't matter too much. It's mostly preference and depending on your case. FPM will process that request, send back the information for Apache to just serve it to the client. So Apache won't do any of the processing. And if you are using pre-fork, or if you don't know, you probably are using pre-fork, I strongly suggest that you look into one of the ways of using FPM. It'll make your life a lot better. All right, so here's what the info page looks like. You can see the now server API changed to FPM fast CGI. So when you install it, go check for that. It should be there. You still tune it the same way, looking at max request workers. That's the directive that really matters on Apache 2.4. And if we follow our rule of thumb math, we can see that the average process is about 8 megabytes, which is super extremely low. We keep getting lower as we move up in Apache versions. But this gives us about 64 max request workers. When we try to set it to 64, you're going to see, I don't know if it's kind of hard to read from back there, but you see warning max request workers of 64 is not an integer multiple of threads per child of 25. So in this case, what it means is you can just blindly set it to whatever number you want. It actually rounds it down to 50, because that's the closest multiple of max pair threads, or threads per child, I'm sorry. So they need to match up. So instead of letting it round down to 50, I went ahead and bumped it up to 75, just because the process was so low. So can you say that again? So the number has to be a product. In this case, when you go worker, the max request workers needs to be a multiple of threads per child. So if you wanted to put 64, you could change threads per child to 16? And that would work just fine. But you can only use so many threads per worker, so it wants them to match up properly. So you can leave the, I could have left 64 there, but it would effectively run at 50. So I went ahead and bumped it to 75. All right, last of the Apache 204 PHP FPM, we're going to look at its event, which I mentioned earlier is the newest flavor of Apache modes, and it adds a synchronous processing. This makes it a little more like Nginx, and supposedly better and more responsive. But remember, if you're using HTTPS, it'll fall back to working exactly like worker mode. So depending on the site you have, it might not even be worth to set up event, or you can set up event and leave it alone. It'll work just like worker. All right, here's the info page. Again, with server API, being FPM, fast CGI. Again, default market request for event is also 150. Let's do the math on that. And it looks like the average Apache process, actually, once we looked at it again, it was an 8 megs, I'm sorry, it was 4 megs. With maximum RAM usage with the default of 150, it would be about 600 megs, which is almost where we want it. So I went ahead and set it to 128. It defaulted to 125. So it got so close that, you know, no worries on that one. We really didn't have to come down too much from the default. All right, so we're done with Apache for now, and we go what's called the Lemp Stack. Anybody here run a Lemp Stack? All right, so we got a few. The E is actually not an E at all, it's for NGINX, which is NGINX. And it's known as Lemp because it's Linux, NGINX, MySQL, and PHP. It's another open source web server. It's claimed to fame. It's designed and written with performance in mind. So this is performed very well right at the box without having to do all that stuff we did with Apache. We will not be doing any tuning up for NGINX just so we see how it stacks up without being tuned at all. All right, just like Apache in worker or event mode, NGINX does not process the PHP. It does not have a mod PHP or anything like that. It also uses PHP, FPM. So if you decide you want to take your Apache installation to do worker or event and use FPM in the back to process the PHP, you might also decide it's a good time to try out NGINX because you're going to be doing a very similar setup. All right? And here you can see when you set that up, server software will show NGINX instead of Apache. All right, we got HHVM and Apache. So anybody here have HHVM? Cool. It's the hip hop virtual machine. Thank you, Facebook. And it's a different way of doing PHP. It does not use FPM or mod PHP. It uses HHVM. It's actually what's going to be compiling your code. It's adjusting time compiler. I'm not a computer scientist, so I'm not going to get into what JIT is, but it's supposed to make your code a lot faster. It's not a web server. Earlier versions of HHVM were allowed you to run as a web server, but not anymore. So for this example, we're going to be using Apache 2.4 with HHVM as a CGI processor, and it will work much like what we just covered with FPM and Apache. So it's got a couple gatchas. It's not 100% compatible with all existing PHP code. It's the project's stated goal to be compatible with everything, and they keep testing and adding more and more frameworks to this list, and they're really diligent about it. But it's up to you whether you want to take the plunge with this. WordPress is not listed in this page. It's one of the compatible frameworks. I don't run this in production, but in all my tests and everything, and I did a little bit of research online, I don't think there's any issues running WordPress on HHVM. But it's entirely up to you. The second gacha, and I don't think that's big, is it only runs on 64-bit operating systems. So if your server is 32-bit, no HHVM for you. All right, if you try running PHP info on an HHVM machine, this is what you get. Very minimalistic. It lets you know it's working, but it kills all those options and everything that we always like to go and look at. This is what you got. All right, another stack we're going to look at and test today is a HHVM with NGINX. So we saw Apache, Apache with FPM, Apache with HHVM. Now we're also going to be using NGINX with HHVM. Instead of using FPM in the back, it's going to use HHVM. I don't have much to add about this except that I really expect this combination to kick some serious ass. So, all right, last of the bunch. Lighty. Lighthttpd, aka Lighty. It's another web server. I don't use it. It has a follow-in and it is kind of was popular. I think it's worth mentioning and putting it to the test, but I don't really have much experience with it at all. As in previous examples, Lighty also runs with FPM. Anybody here ever run Lighty? So, not anymore. Well, it's there. Now you know about it. All right, so let the games begin. Anybody knows what that is? Argentina? Yeah, it is. It's the la doce. It's the bucket juniors. Anyways, let me not go there right now. So, if it wasn't clear by now, the results of these battle of the stacks don't mean much. They're just for fun and just illustration purposes. We want to see how these technologies behave with some very simple tests, minimal configuration and tuning of these servers. Some are actually running stock configuration. It's a lot of fun to run through these and it might be surprising to see what the results give us. All right, so all the stacks, like we said before, were set up in equivalent servers. It wasn't the exact same server that just kept changing all the software on, but they're equivalent. They're all on digital ocean, they go by RAM, it went to 14.04. Ten bucks a month and let's see how much power we can squeeze out of one of these. They are all running a default installation of WordPress and that's our target. So the load test goes straight into an index PHP on WordPress and gets what it gets. The rules. And you don't have to remember them all. They're going to be pretty self-evident once we get into the games, each stack gets paired against another randomly. So all the eight that we saw were actually mixed them up and let them fight each other. Each stack gets a vanilla installation of WordPress. We run all the tests using loader.io, which is a third-party service. So I'm not running them from my own network or from my own laptop. This is a third-party service that will distribute the tests and make them as even as possible. This stack with the better average response times moves to the next round. And each round's test is progressively harder than the last. That makes a lot of sense, right? The winner of the third round will be crowned last stack standing. So simple enough. First I wanted to go ahead and show you what this is a simulation of the test. So I'll let you see what it looks like when we're running it. Yeah, there you go. So there you go. You got the client's line. You got the average time. In this one, I was actually testing some static pages. So you can see I'm hitting it with about 30 to 40 requests per second, and it's staying at about 10 milliseconds. So that's kind of nice response times right there. But all the tests look like this. In the slides you're going to see, I got some short URLs with each test. You can go and actually replay all the tests that we did on this one. All right. This is how I decided the order of how they're going to fight each other. Put them in an array, shuffle it, print it out, and that was that. This is not the first time I do this presentation. So if you go back and there's actually some videos, different results each time. So we just let the randomness kind of take its course and shape what we are about to see. All right. Here's the bracket. So we're going to start with Apache 2.4 Worker against HHVM Apache, HHVM Nginx against Apache 2.4 Event. So it looks like all the heavy weight is on the top of the bracket, right? Lighty against Lamp 2.2, and then Lamp against Lamp 2.4 Prefork, which would be the default. The first test that we're running in this round is 60 clients over 60 seconds. So the server gets hit about once a second. It's pre-light load, but let's see what kind of response times we get. Who's taking the bets? I'll be glad to. All right. First one, and here are the URLs that I was telling you about. You can go to those URLs and actually look at the test and corroborate that my times are accurate and that I didn't just, you know, put whatever results I wanted to make my favorite server win or anything. So Apache 2.4 Worker with FPM versus HHVM Apache. So why not Apache is going home, for sure. All right. So HHVM Apache just shows some serious numbers against one of the most advanced Apache setups of the group. So Worker is one of the best ways you can run Apache, but obviously not compared to HHVM. So it almost had the response times in half. Again, for this situation on an idle server with 60 clients over 60 seconds, when those numbers change, anything can change. So please run the test appropriate to your stack. Okay. I want to make sure you don't run out of here saying, well, run HHVM Apache right now. It's going to be awesome because, you know, it might not be the right solution for your application. All right. HHVM NGINX against Apache 2.4 Event, the newest way of running Apache 2.4. So who's for NGINX on this one? All right. And who wants Apache event? All right. NGINX is the favorite. And yep. You know, it kicked us. 37 milliseconds. That's amazing. I mean, 66 milliseconds is amazing performance, too. But 37, again, HHVM seems to really be something that you take into account and look at. It's actually not as complicated to set up as it sounds in the beginning. And warpers run pretty well on it. It might be worth considering. So in the first two rounds, two of the most advanced Apache setups are gone. And they both lost to HHVM. So HHVM advances to the next round on both occasions. And this time, it does it with NGINX. Right? In this match, we got Lighty with FPM versus the old Apache 2.2 pre-fork, which is probably the most popular setup out there. So none of us really know much about Lighty. Any bets on this one? Lighty? Anybody else Lighty? Apache? OK. Nobody wants to bet here, but let's see. Whoa. And Lighty's actually putting some decent times there. All right. Lighty wins. It shows some very promising numbers. 2.2 pre-fork is the worst test thus far by a big margin. OK? So really, if you're running this, just maybe at least upgrade to 2.4 and get a reduction of about, that was it, 60-some percent that you would do, right? So if you're still on Apache 2.2 pre-fork, get away from that. Switch it to worker mode. And use FPM. Upgrade it to 2.4. Do all of the above. It's showing its age, and it might be time to just retire it. All right. In the last match this round, we got Lemp against Apache 2.4 pre-fork. 2.4 pre-fork being the default setup that still uses ModPHP, bottom 2.4, and Lemp being the seaside means favorite, right? It's like, you always talk to a seaside and they're like, no, I'm NGNX all the way, and Lemp's the one that's been around the longest. So who's for Lemp? Close one. All right? So Lemp wins, but just the hair. And keep in mind NGNX is running with the default settings, whereas we tuned Apache a little bit, but only a little bit. And one thing I'd like to point out is what I was saying earlier is that even on pre-fork, version 2.4 performs three times better than 2.2 pre-fork. So upgrade Apache. Do just that. And you just got yourself a 60% improvement. All right. So this is what our bracket looks like now. We are going to have the battle of the HHVM. So one of those is going to go home, and they're going to make it to the final. And then we've got Lighty versus Lemp. I think there are two interesting matches there. So three out of four Apache stacks already gone. NGNX actually won both its battles. So go NGNX. And Lighty, it surprised me when I ran the test, but he made it this far and with decent numbers. So the next test for this round is 120 clients over 60 seconds. So we double up the number of clients. We're about two a second. So in this case, the performance is not linear. Some servers might perform better when they hit the sweet spot of how many connections they're accepting. And some others might actually get out of whack. So don't expect that just because it was 30 milliseconds with 60 clients, now it's going to be 60 milliseconds with 120 clients. It varies. So let's see what happens. We've got HHVM Apache versus HHVM NGNX. So they're both really fast. One of them is going to go home. He's not going to make it to the finals. So hands for Apache. So hands for NGNX. All right. And Apache wins. They're both close, but Apache moves to the next round. NGNX goes home. So surprising also. And I was rooting for NGNX, but like I said, I do the random setup. I let them fight each other. And these are the actual results. All right. And now we go Lighty, the Cinderella story. Made it this far. We're on too much madness. So we've got a dark horse there. And we've got the old seaside in your favorite, Lemp. So let's see another show of hands. And I'll stop doing this. No, I won't stop. Let's do it. So who's in for Lighty? Lemp? He's got a follow-in. Nice. So I see NGNX is kind of a favorite in the crowd, too. Very nice. And boom! Lighty takes the match. So yeah, another upset, right? Lighty's in the finals. Who knew? All right. Very close the results. They both performed super well. I think one constant you can see here is that offloading your PHP processing to outside of the web server is absolutely the best thing you can do. You know, whether it's HHVM or FPM, get it off Apache. Don't use modPHP anymore. All right. So close. But we've got a final here. HHVM Apache versus Lighty. All right. So who's going to go for Apache? Yeah. And Lighty? He's going for the underdog. He's going for the underdog. I like that, Russ. Thank you. All right. So I think we already have a good idea who's going to be fastest. But, you know, we're going to run through the test. And remember that reliability, like we said at the beginning, also plays a factor, right? We didn't look at memory usage and everything on these platforms and how much FPM is actually taken of the CPU. So at some point, you might see that one setup, even though it's faster, may not be as reliable for your kind of traffic. So always keep that in mind. So because too many errors, when you're serving pages, it won't matter how fast you can serve if you can't do it at all. So for this test, what I wanted to point out, we quadrupled the initial test. It's 480 clients over 60 seconds. That's actually getting into some hefty traffic. And let's see. All right. So HHVM Apache blows it out of the water. It's a clear winner. But Lighty made a great showing. I think this is still amazing performance with some pretty heavy traffic. I'm not telling you to go and set up Lighty because probably, you know, there's not a big community. You're not going to find a ton of answers and stack overflow when something goes wrong. You know, just... But keep it in mind, you know, it's something that's out there and it works very well. HHVM Apache, I think, just shows that Apache has took the test of time, that it's progressed a lot, that its performance keeps increasing with each version, and that HHVM, you know, this new addition to our toolkit, really has some to offer. I'm not running HHVM in production at all. I got one LIMP server. I got another one that I do Apache 2.4 with Worker. Those setups are working very well for me, so I haven't had a need to move to HHVM. But this is certainly something to keep in mind and maybe experiment with. All right, so HHVM Apache, champion of the Battle of the Stacks, Workham ATL 2015 edition. But now that the games are over, I want to take a moment to tell you about a true champion. Takeru Kobayashi. You guys know who this is? You probably remember him, you just don't want to say it. Takeru became famous when he won the Nathan's Hot Dog Eating Contest in July 4, 2001, while at the same time breaking the Hot Dog Eating World Record. So until that day, the record had been 25 hot dogs in 12 minutes, which is pretty impressive. He ate 50. He didn't just stop at 26, which would have broken the record as well. He wanted to push and see how far he could go. So his honor, we're going to do a Kobayashi round. Let's take the winning stack, HHVM Apache, and let's push it until it starts breaking. And see how much performance can we get out of this $10 server when we use Apache with HHVM. So I wanted to see how many clients I could throw at it and still get zero errors over 60 seconds. The results? I hit it almost 2,500 times over 60 seconds and still got a response time of half a second. I think that's pretty impressive. If you can get this kind of performance out of 10 bucks by just changing the server, the stack you use, or tuning it up a little bit, definitely worth looking into that before you start throwing more RAM at the problem. So I played around with several tests until I found I think it's a pretty good compromise. Once I got past this point, lots of spikes, lots of errors. So this is kind of like the sweet spot for this setup, with this traffic, et cetera, et cetera. Always look at your own situation. There are other ways. There are a lot of options available that don't cost anything. So exhaust all these before upgrading server resources. All the tests were done at a server that cost $10 a month. We now know it can withstand a pretty hefty load with some minimal configuration improvements. Optimize for speed and also reliability. There's no point in serving pages really fast if the server can't deliver them at all. For someone else, it may not be the best fit for you. So always careful when you find some blog posts that promises they have the best setup. There is no best setup. It's the setup that works for your application. So look at your numbers. Use the rule of thumb math I gave you. Try different stacks and find what's the best you can get out of your existing server. And then last but not least, experiment, combine. Don't be afraid, there's a lot to gain. So thank you very much. I'll take any questions if you have them. If not, we can just mull them out. Yes? Moving, reseller count and setting up something in digital ocean. I've been looking at digital ocean. I've been looking at SSL, VM, like that. Right. You know, I may have 40 sites on it, but they're not going to get that many hits. And I just went with a length back. You're going to run into putting in a lot of time to maintain your server. So if you're not looking at really, I mean, if you enjoy maintaining servers and playing around with this kind of stuff, go for it, of course. If it's something that you're just looking to solve your business problem, you have sites that you need to host and need them to perform well and not worry about, you know, how they're maintained, well, let somebody else do the work. There's some awesome WordPress-specific hosting services. There's other shared hosting services that work very well. And you will never have to worry about what Apache version you're running or, you know, if the server goes down in the middle of the night and there's the redundancy and this and that. There's somebody else taking care of that for you. However, if you want to learn server management, yeah, by all means, go to digital ocean, get a $10 server, start playing around with it. There's a ton of really cool stuff to learn. So I personally don't host my own email ever. It's the worst thing you can do to yourself. Right. So let's say your site, you know, say you're hosting a blog and it lands on the front page of some very popular site. And all of a sudden, you've got 5,000 people trying to hit your site at the same time. Now it's your problem, because that's going to go down. And you're going to have to do some learning very quickly on how you scale that server, how you have to say we were running the pre-for we were talking about, you know, the default Apache. Well, you're going to get a crash course on how to set up your max workers to work in conjunction with how much RAM you have and all that. If you're not interested in learning all that, just let the hosting company worry about it. You would still have to maintain it yourself. So when the new version of Nginx comes out, are you going to do the upgrades? Are you going to patch the operating system when there's security updates for it? So there's a lot that goes with maintaining your own server. I've got to run to the Roots talk, but I am plugging Bedrock really quick. The Roots team also has Bedrock as a stack that also finally offers HHBM. So there's just a way that you can enable. I definitely don't recommend switching between the two, but there's an ansible playbook. You just fire up Bedrock. Cool. You can play around with HHBM and it's traditionally a lens. Awesome. So yeah, another, you know... I'm getting off of managing a VPS right now because I had a long time ago, so not worth it. Use code Battle of the Stacks for six months for... Just kidding. Don't use the code. Yeah. About reliability, you mentioned it in the report. Have you noticed in your experience any differences between the stacks with reliability? Yes. I started learning about all these things because I tried to run, aside for a client, that was getting a lot of traffic and we were running on Apache 2.2 with ModPHP, and it just wasn't cutting it. It was, you know, just crashing and crashing and crashing and then I started looking into all the different modes, ended up with 2.4 on worker mode and actually learned to do some tuning and everything and without increasing the run, we actually, from there, we went from using 16 gigs to using four gigs and I always had idle capacity. So doing tuning really saved us a ton of money. Well, thanks everybody. This is how you get in touch with me. If you have any questions or, you know, send me an email, find me on Twitter and, you know, we can chat about some of our performance or development in general. Thanks everybody.