>> Hi, I'm Donavon Brown,
Principal DevOps Manager for Microsoft.
Load testing is a great way to find
issues in your software before your users do.
Make sure as your application grows in popularity,
it is ready for the additional load.
There are several ways using Azure,
Visual Studio Team Services,
and Visual Studio, to get started with load testing.
Let's jump right in and let
me show you how you get started.
If your application is already being hosted in Azure,
the quickest way to get started
is just to go to that app service.
On the app service blade itself,
is a way for you to start a performance test.
Just scroll all the way down to the developer tools,
and here you're going to see Performance Test.
When you click on "Performance Test",
it's going to give you the ability to create
a very quick and easy performance test
right here in the Azure Portal.
To get started, you just click on "New", and from here,
you get to choose the URL for which you want to test.
This happens to be a URL for a web service.
But if I already hit this URL directly,
what you are going to actually see is a web page.
That's not what I want.
What I want to do is drilled into the API.people,
and when I click on this,
you're going to see that it's a web service
bringing back some XML results.
That's what I actually want to load test.
I'm simply going to copy that,
and then paste that as the URL that I
want to go and to do a get against.
When that is done, I'm then able to give the test a name,
decide where in the world that I want to run the test,
and then also what the load that I want to
run on this particular test, and for how long.
I've already done this, and what you'll see
is you'll get the test results just like this one.
These are the results of a load test running with
250 concurrent users against that same endpoint.
You can see the response time,
you can see how many failed requests that we had,
and get a quick overview on,
what's the health of my application?
And will I be able to
sustain the load that we're looking for?
Also down here at the bottom,
you'll be able to see the CPU time and memory usage to
see if the scale unit that you have is big enough or not,
and if not, you can decide to scale it up right
now and make sure that
you're going to be ready for the load.
This information is not only
surfaced here in the Azure Portal,
it's also serviced inside a Visual Studio Team Services.
If I have to click on this link here,
I'll be taking to the account that's
backing this particular application.
From here, I can simply click on my load test,
so I'll go to "Test", and then from here,
I'm going to click on load test,
and I'll be able to see
all the load tests that I'm running
including the load test that come from the Azure Portal.
If you remember the name of that particular test,
which I believe is this one here,
we can now see the same results that we saw inside of
the Azure Portal directly from
inside a Visual Studio Team Services.
If I were to open this up,
you'll get very similar charts.
So, let me know again the average response time,
the user load, how long the test ran,
and if there were any errors or not.
It also shows me my slowest request,
of course we only made one,
so that will be the slowest request.
Now you can also create
that exact same test from here but you'll
have more control if you do it
from inside a Visual Studio Team Services.
For example, not only can I create
the same type of User-Base Test with the URL,
but I can also use a Visual Studio Test,
which will learn how to create here in just a moment.
I can use a archive file from Fiddler,
if you've been using that to track your traffic.
Or I can even use
a Apache Jmeter, if you're using that instead.
But let's duplicate the same test that we
created just a moment ago and see
that we actually have more power when we do
it inside a Visual Studio Team Services.
We're just going to go ahead and give
this a temporary name,
and I can add additional URLs
which I could not do before.
It was only one URL,
and I could only do a get.
But here inside a Visual Studio Team services,
I can do a get, post, put,
delete, all of the different types of
methods that I'd want to perform
against my particular endpoint.
If I were to choose "Post", for example,
I can come down here and give it
a content-type and actually
give in the information that I'd want.
In addition to that, I can click on "Settings",
which allows me to set the duration,
also change the load pattern
that I want to apply to my application.
Do I want all the 250 people to hit it all at once?
Or do I want to slowly build up to
250 as the application starts to become more popular?
I'll do constant here for now.
I can choose the number of people, the warm up,
and I can also control the browser mix which I
could not control from inside of the Azure Portal.
Another thing that I can do is choose from
a much larger list of regions.
As you'll notice, this list is
much larger than the list that
we had inside of the Azure Portal.
If you've already taken the time to set
up your own physical rig,
you could actually use that rig here as well.
But the advantages of using the Cloud,
really make creating your own rig
a thing that we don't do anymore.
Now, you get to use the power of the Cloud to provision
all the resources necessary to
generate an enormous amount of load,
and then when you're done, get rid of all those machines.
Plus you're having those physical machines yourself.
Once you're done with that, you're going to have a test
very similar to what we did before,
and your results are going to look just like they
did when they came from the Azure Portal.
Here I can open up one of my runs.
Again, I can see my average response,
the number of users I used,
how long I ran it, and any errors that I
had that failed to that particular test.
Now, you may have noticed that,
as we move along,
we're getting more and more control
over the load test that we run.
There's one other way that you can create your load test.
One of them is directly inside a Visual Studio itself.
There is a solution type that you can create where you
can author the test that you want to run.
For it to open up this web test,
you can actually see the request that I made,
and let me bring up the properties for you.
When you bring up the properties,
you'll see that there's so much more control.
Not only do I have the control over the method,
but even the version of
the transport protocol that I want to use,
the URL that I want to actually hit,
and I can even control the headers that get sent.
If I want to enable Gzip for example,
or if I want to make sure that it sends me
back XML vs Json,
I get to control all of the headers,
which are really important.
Another thing that's really important is your ability to
add validation to the request and the response.
In the previous test, we were sending
the request and if we were getting a 200,
we assumed that everything was good.
But what if I got a 200 but the data
inside of it was not the data that I was expecting?
We were not able to test that
with the other two methods but here,
I can add a validation rule.
Because I know I'm going to be getting
XML back, I can say,
lets go and require that there be a first name tag.
Then that first name, let's say for example,
Jessica is the value that I want inside of it.
I can use these tags and
these validation rules to be able to verify
that I actually got the data that I wanted to.
If we run it at load,
weird things don't start to happen.
So, again, we're starting to get
more and more power and control
over the load tests that we're running
as we get closer to a Visual Studio.
Once you have your test authored,
you can go off and create a load test.
A load test allows you to control
what computers are used,
what addresses are hit,
what browser mix that you want,
what network mix that you want as well.
If you wanted to pretend
that some people were coming from
a phone using 3G or 4G versus coming from a landline,
you can do that to make sure that
the responses worked the way that you want to.
You also have the ability to set
thresholds which are really important.
Response times are great,
but what if I wanted to check
other metrics on my application?
Here under the 'Load Test" settings,
I'm able to drill into any item that I want
to and actually set a threshold.
A threshold is a value that I want to
be watched during the execution of my test,
and if those values are ever eclipsed,
I'm able to then be notified
that at this point in your test,
we had a threshold violation.
You weren't able to sustain as many simultaneous users,
maybe your response time went up,
your error accounts went up,
but you are now in complete control of what's
important to you and what needs
to be monitored during your test.
Once this is done,
you then execute the tests like we did before,
and we're going to be utilizing
the resources that are in Azure,
to generate the load for you.
If you want, again, you can actually use
your own laptop for a small load,
or set up your own rig,
but I would encourage you to make sure,
you really don't want to use
the stuff that's in the Cloud because it's really,
really nice, and it makes life so much
easier than you have in the provision a rig yourself.
Once the test is done,
you'll be able to see all of the
results like we did before.
But we get much more detailed results when
we actually run them inside a Visual Studio.
Using this full testing,
I can see the thresholds that
were violated, and as you can see,
I set a threshold to see what
my requests per second were going to be,
and if they ever dropped below 100,
I wanted to be alerted,
and at one point during my test,
they dropped to 83.26,
which let me know that at some point,
my infrastructure was not able to
sustain the same number of users that I wanted to,
and I might want to go investigate
this and figure out what's going on.
Any threshold violations that might have
happened would have been shown for me here automatically.
I can also go back in and
look at the performance results,
download the details, and see all of
the information that was happening
during the execution of my test.
Now, load test is great
as a one of that you might want to go off and run,
but being a DevOps guy,
I want to figure out how I can do this all
the time throughout my entire pipeline.
What's really nice is using Visual Studio Team Services,
you can take the information that I just showed you,
and incorporate it into
your build in your release pipeline.
I'm going to take you to an existing released pipeline,
and I'm going to show you the task that you can use to
run these tests during your actual release.
In doing so, you no longer have to stop
what you're doing and manually run them.
Your release is going to tell you if you've
made any detrimental changes
to the performance of your application
while you're deploying your code through your pipeline.
A lot of people do this during
their QA or
their staging environments which should look very,
very similar to their production environment.
In doing so, they're able to
determine if the changes that they've made,
have had a detrimental effect
on their actual performance.
As you can see here on my release pipeline,
if I go to the QA environment and look at the task here,
I actually happen to be running
a performance test as part of my release.
There's other tasks that I can use as well.
So, if I come here and I simply search for load test,
you will see that there are several test tasks that I
can use to run load test as part of my release pipeline,
allowing me to make sure
that none of my code has actually may
had a detrimental impact on my performance.
Before I go, I want to encourage you to visit
docs.microsoft.com to learn more about load testing.