 Hey, my name is Mike Penisi and I work at Boku. I train people about how to test front-end applications and this screencast I'm going to talk a bit about getting a server ready for stress testing Before we start I just wanted to point out this article on Boku.com This is the basis for this screencast and it goes in a much more detail than we'll be going into today It has a bunch of references so you can do some further rating and really get more detail that you'll need to Do this yourself Having said that I hope this will be useful just to kind of get an overview and see what this whole process feels like What we'll be doing today is looking at first a production server that I've set up just to kind of simulate what Your production server might look like then we'll be creating an AMI which is an Amazon machine image from which we can spawn as many stress testing simulators as we want and Finally, we'll actually run a basic strength stress test so first we'll look at our Fake kind of production server. So this is the AWS interface the Amazon web service interface And we're looking at a list of our ac2 instances is running right now. You can see that I have one running already It's called my production server So as it turns out I'm just happened to be running my production server as an ac2 instance as well So as I point out in this post your ec2 instance, I mean your web server might be running anywhere It doesn't really matter. It just happens to be in this case running from ec2 so here I have two connections to my web server and One that will be using later, which is called the bee control And so that's how we'll actually be administering the stress test, but for now we'll stick with the server So the first thing you'll want to do with your server is make sure that you have Really high limit on the number of open file descriptors You can have and so this seems a little bit surprising because we're not really working with that many files necessarily what we're interested with is Connections it so As it turns out if you're if you're running Linux then the way that it's operating under the hood is for every TCB connection be it a web socket or a long polling XHR It's going to have a file descriptor open in the operating system so if you have the default limit of 1024 files files that can be open Then that's the maximum number of connections that you can sustain So it's gonna be important to raise that to something that's above what you need So the way we'll do that here is we'll edit this file in Etsy Let's see it's security So I'll go to the end and I've been here before so I've already set this up to be for any user We're setting the hard limit on the number of files to be 40,960 so that's well above what we will need today Okay, and so last step is to actually set that 60 oops It is so now we can kind of check it good All right with that out of the way. I wanted to take one minute to look at the different ways we can monitor our The load on this server as we're running the stress test. So traditionally people can use Top which is this utility to look at system resources Kind of in real time. You can see the screens updating with information about all the running processes CPU information memory information And this is this is pretty good if you want to get a little bit fancier You could also download and install each top you can see here that we have color We have kind of more graphical ways of looking at CPU usage and this thing also responds to mouse clicks So it's a little bit easier to use interface wise But for our purposes, I really like SAR which is a way to look at real-time information about Your system so what we'll do is by default we'll just say SAR and dash one and so this is just going to make SAR print out information by default is printing out CPU usage once every second so we could do SAR 2 and that would be once every two seconds, but The Important thing is that you can actually change the what the information that you're looking at so we can look at information on sockets for instance And so now we're looking at Total number of sockets TCP sockets UDP sockets all this stuff and today we're interested in TCP sockets specifically so What we'll do is we'll also give it an output option. We'll write it to Results that SAR for instance and so now the Nothing's really changed here. We're still seeing the information, but when we finish running we can look and see that there's a results That's our file We can cat that out if we want to but it's not really useful It's binary data. So instead what we'll do is we'll use SAR itself to look at this. So we'll use SAR and sock and Use the F flag and give it results that SAR and so now we're seeing kind of it just a playback of the information we just recorded so What's nice about this though is that SAR is actually recorded despite just looking at information Sockets stars recorded all the information that it collected over the course of that test So if we didn't pass this this flag We would be looking at the CPU utilization During that time and so we could use the same interface that we did when we were monitoring system activity to go back and look through the logs of all the system resources and so this will give us a lot of flexibility when we're coming back and Analyzing what happened during our stress test. We can dig down into different details like memory utilization network utilization CPU utilization and All these different flags are going to be in the manual page for SAR and you can go through and see what those look like And what kind of information you can kind of drill down into so that's really great to have this as kind of a resource when you're done This results file that has comprehensive stats on your system over the course of the stress test