Why would you use Cloud for load testing?
Well, it brings a lot of benefits :
- it's on demand
- you can switch your injectors on and off as and when you need them
- it's very scalable because not only can you switch those injectors on and off, you can switch off and on as many injectors as you need
- it's also geographically diverse. So you can switch those injectors on and off around the world using Amazon’s redundant data center.
- it's very low cost.
The cost of running these machines is calculated in cents per hour. If you take a look at the Amazon pricing, you’ll see it's really affordable sort of thing that you can just use with credit card. Also, the data transfer costs are very low. In fact, it's particularly well setup for load testing because the data is charged out but not in. So it's typically setup for a web server model. Whereas in load testing, we're taking the reverse of that model and we get a lot of data coming in, which Amazon are not charging.
Cloud for load testing scenario
We’ve got our application; in this case, it's deployed in North America. Normally when we do load testing, we’ll test from the data center and of course, you can use AgileLoad to do that. However, our users are not based in the data center and while the traffic ultimately reaches that last mile of data center, if you want to understand user experience from different locations around the world. For example, Europe, Asia or South American and so on, then we need to test from those locations. We can use the Cloud to do that. We use in Amazon EC2, which has locations around the world. Particularly in the US, Asia, South America and Europe, so by having AgileLoad inside of those locations we can then use those locations as injectors and thereby evaluate user experience from around the world.
Preconfiguring Amazon EC2 for load testing
So now for some of the science. Let’s take a look inside one of these clouds. In fact, these clouds are really data centers, which are full of thousands of machines, which use virtualization. You can then spin up and spin down these virtual machine, which can be preconfigured with AgileLoad so that they can be ready to run as injectors. So if we drill down further into just one of these machines, let’s take a look at what we need to make this run. Well, if we’ve launched an AgileLoad instance and there are two things that we need to do. We need to
make sure that the firewall is configured. So if you've already preconfigured Amazon EC2, then you won’t need to do this because you’ll already be setup as this screen showing here. If not, then it's in the video about preconfiguring Amazon EC2 for load testing. The other thing we're going to need to do is tell the AgileLoad instance about the
external IP address. There's a short clip following this, which will actually explain how to do that. So once our injector instance is ready, we're then ready to connect it up to our AgileLoad console, which is sitting on – perhaps on your desk or in your company, which also needs to be configured.
You need to know
- the external IP address and the internal IP address and the firewall on the company side needs to be configured to allow AgileLoad pull us through, which is 15140. This can of course be configured. So now, you can see how the console connects via the Internet to the remote injector in the Cloud.
Configuring AgileLoad for Cloud performance testing
So let’s now look at how to configure each part of AgileLoad. We have the console and the injector. We need to configure the console with the IP address. ( If like me, you're using a changing dynamic IP address by typing in, “what is my IP?” Google will come back with your IP address. )
So I’m going to go into the AgileLoad, which is the green gazelle. Right click and choose configure. Bring this screen down so you can see it. In the box, which I can enable by clicking custom and I type in that exact IP address. The box above is the internal address. The box below is the external address. I’ll add the port 15140 and pop forwarding is switched on. Then my console is configured. I want to launch an injector in Northern California, so I choose Northern California and 82 and click launch instance. This using the classic wizard and clicking continue. I want to go to community AMIs and I want to find the AgileLoad Amazon image. So typing that in, I find it. I choose it by clicking select. I’m going to use a small machine type. It's the cheapest to run and click on continue. If I wanted to run a larger test, I might want to choose a larger machine type. I’m going to give it a name now. So I’ll just call this injector west. Click on continue and my existing key pad. This is a certificate file, which we cover in the Amazon EC2 video, also on the channel. Also, we choose the firewall and setting that up; I’ll show you in the Amazon EC2 video as well. So I click on continue and launch. So let’s just close this screen and we can see it’s pending.
Fast forward and now, we can see it’s running. So this is great. I’m not going to associate an IP address. I’ve already set one up. So I associate it with my image and associate. I could create a new one; again, I’ll cover this in the EC2 video. Now I’m ready to go. If I go to instances, I can click on connect. Download a shortcut file. Click on that and it launches a remote desktop. I type in the password, which is AgileLoad888 with a capital A and capital L. Click on okay. Now we're going to connect remotely to this machine in Northern California with AgileLoad already installed. There it is the green gazelle.
I just need to configure this with the internal and external IP addresses. So I have my internal address. Click in on custom. I then need to put in the external address, which is in the connection bar at the top. This is the same IP address that you configured inside the EC2 dashboard. Clicking okay, we can see the gazelle goes back to green again and it's started and we now have a setup AgileLoad injector and console where they can now talk to each other. Going back now to the AgileLoad console, I’m going to open up a job I already created, which is Cloud Test. It's already preconfigured with monitoring information that I want to check. So I’m checking my injector’s health and the health of the server that’s the target of my load. I’m dragging and dropping the script that I want and I’m going to give these guys a name, EU customers because they're going to be based in Europe. So I’m generating this load from Europe. Hence, I need to use my European injector. You can see it says 79.125.110.02. I’ve already got that configured in my monitoring section. I set that up very much in the same way that we set that Northern Californian one up.
Running my performance testing job in the Cloud
I’m telling it to run manually till I stop and the script is just going to run one iteration per a scenario iteration. I want to put in 1,000 virtual users and run them up over 10 minutes. I’m going to set my HTTP options. I’m not going to use any special browser here. I’m just going to go down – I’m going to make – it's a little bit light for this server. So I’m going to ignore static request.
Then go across to network options. I’m not going to set anything there and I’m not going to set any service level agreement options here. I’m going to click on launch. It's asking me to save the project so I’m going to do so and it then launches the job checking the injectors and configurations and so on. We’ve got the global HTTP view. So we start to see the redline. At the top is how many virtual users we have running right now. So we have just over 20.
I’m going to look at the health of my servers. So I’m going to go into the Windows tab. Double click overview and we can see CPU time is blue at the top. That’s at idle so it's nearly 90 percent idle. So I need to put in some more users here. I’m going to duplicate my European users and I call these Californian users. I’m going have them generated from the injector I created in Northern California just now in the video you saw earlier on. So that’s the IP address of that machine is the same IP address we were using earlier on in the video. I’m going to click on start. So there it will start to run. I’m going across to my folder view again. I’m going to go into page timers.
What I want to do is compare European with Californian response time.
So I’m going to the plunt homepage and checking both of those for other if you saw the EU user and injector west. We can see here, the blue line is that European response time and the redline is California response time. So I’m going to add on the number of users there. So you can see where on the left-hand side we’ve got response time in milliseconds.
On the right-hand side, we’ve got the number of users. Now I’m opening up and going to drag across the Windows collector for my server. So we're going to look at the processor for the server.
See how that’s doing. Now it's one the left-hand side, which the scale’s wrong. So I’m going to move that across to the right-hand side scale. So it's going to share a scale with the virtual users and make the line a bit thicker there. So it's a yellow line. You can see it's about 20 percent utilized.
We’ve got about 400 users on. Whoa, all of a sudden, it's 100 percent utilized and page response time has gone through the roof whilst we’ve hit nearly 500 users. So that seems to be our limit. So thanks so much for listening. If you want to see more about setting up jobs and test execution, check out some of the videos with those titles. Hopefully see you on the website.