[Music]
hello hello welcome to solving with AWS
solutions your deep dive into
architecture is built by AWS that are
ready to deploy instantly in the cloud
I'm Rob your host joined today with a
man who lights sails in the Hudson River
Tom hello and welcome back today we will
be exploring distributed load testing on
AWS a solution that simulates thousands
of concurrent connections to a single
endpoint so really a useful tool for
anyone entering on their application
development and performance it's
absolutely right all right let's get
into it so table talk to me about
distributed load testing what exactly
are we testing as part of this so
imagine you're a developer you've built
your application you know it works
because you've done your unit testing
what you need to know next is is this
going to perform in production and is it
going to perform at scale so scalability
is important one user is one thing but
testing it for a thousand is different
exactly right this solution builds built
out a framework where you can easily
test your applications under load by
using elastic container services to spin
up containers that will create hundreds
and hundreds of connections to your
endpoint and you can spin up hundreds of
hundreds of those containers awesome so
this is our landing page walk me through
this yep so like all our solutions we
have a link to a CloudFormation template
this will spin up the solution in your
account with a couple of clicks and a
detailed deployment guide and we also
have the source code available on github
if you want to take it customize it and
do your own thing we have a wonderful
architecture diagram let's walk through
that we do it so the solution comprises
really of a front end and a back end if
we start with a front end we have a web
console a UI that we can use to interact
with the solution and then a API so that
allows you to create tests view status
of tests rerun tests delete tests that
type of operations so the UI comes from
the CloudFormation template this is
where the users actually start
configuring the test itself that's right
so from that we then have the backend
and that comprises really of two things
there's a docker pipeline and then the
actual testing engine itself and where's
the docker pipeline coming from
so the solution uses a open-source
software called torus that a camp there
is a docker image available on docker
hub that you can use and that allows you
to generate hundreds of hundreds of
concurrent connections to an endpoint
it also supports jmeter and gatling
which are other testing tools okay
very common in it this is the actual
testing part of these so this is the the
application that's going to do the
testing and that comes in the form of a
docker image so our back-end pipeline is
going to take that image package it up
for us put and push it out to s3 in the
customers account and then we're going
to use co-pi p-- line and code build to
then build that image and register it
with our elastic container set where is
the actual testing occurring so the
testing itself is being run in AWS
Fargate okay so AWS Fargate is a managed
service that will let you run your
containers on the elastic container
service without having to worry about
networking or the underlining
infrastructure or anything like that so
it's literally just spin up tasks run
the number of containers that you want
everything else is taken care of so far
gates actually really taking care of
that back in area where you don't have
to worry about the scalability of it's
exactly so that's the core of the
solution okay and then around that we
have a lambda function that will take
the requests from our API and that's
what's actually running the the tests so
okay it's going to store a test template
in s3 it's going to store all of the
information that we're collecting in
dynamo and then we're using sqs to queue
up those tasks in AWS Fargate so that we
can start spinning up our containers
alright so can you show me a little bit
about the front-end on how we configured
some of these tests yeah
so it's a nice simple front end there's
a dashboard if we go back to that you
can see here a couple of tests that I've
set up but okay I've got one running
I've got one completed from the create
test page so the warning here saying
that we currently have a test running so
let's not kick off another one okay the
reason for that is all of the all of the
containers will be sending information
back to the same location so currently
it doesn't support multi
tests running at the same time because
no aggregated results would be a mixture
of the two but as part of this UX out of
the cloud formation template we're
gathering some base information on how
to configure the tests we want to run so
give it a name give it a description
task count is the number of containers
that you want to run concurrency is the
number for each container how many
concurrent connections that's going to
create and then a ramp up time and hold
time is how long am I going to get from
start to get up to that number of
concurrent connections and then how long
am I going to hold that test for okay
currently we support single endpoint but
we also support different get put post
and delete operations and you can
actually pass in headers and payload of
body text if so a lot of flexible
information to run as part yeah so you
can there's a number of ways you can
test different types of endpoints do you
have a test currently running so I have
a I do we've got a running test here
this has been running for a couple of
minutes so here's the details of the
test and you can see I asked for 20
containers and I've currently got 20
containers running once that's finished
on the backend each of the containers
will run their tests take the results
and then store that as in the form of an
XML file in s3 and then our back-end
lambda function once all of the
containers have finished we'll take that
information and aggregate it and and
pass all of that information into deines
so how do we see some of the results and
so if we look at a completed test again
here's the summary of what we asked for
and then here's our results so we've got
average response times Layton sees we're
getting a cloud walk met a cloud watch
metric so we can see how we're
performing a number of other data points
and we're also getting a history so you
imagine you could run this once do some
fine-tuning on your on your end point on
your API and then rerun the test again
to see how that improves the response so
developers are able to iterate and see
their results over time with the
improvements for the making to their
application and the most important part
they're seeing at scale that's awesome
so thanks for walking through distribute
load testing you're welcome so that was
a deep dive into our distributed load
testing solution on AWS this solution
moves all the complexities of generating
load to test your applications at scale
thanks for watching
launch this ATS solution or other
solutions via our webpage see you next
time
you