1 Swift Enterprise Demo App & Auto-scaling

1 Swift Enterprise Demo App & Auto-scaling


This is the first video demonstrating how
to use the Swift Enterprise Demo, a demo application that was developed in order
to show the capabilities of Swift-enabled offerings from IBM and IBM Bluemix. This video will be showing the auto-scaling
service in action. The Bluemix Auto-Scaling Service is designed
to automatically scale up or down in response to the load on a Bluemix application. It can add new instances of an application
under heavy load, and remove instances of an application during
calmer periods. The Swift Enterprise Demo is designed to provide
artificially created stress on various metrics so as to trigger the Auto-Scaling Service
into action. Using the demo, we can adjust three different
metrics that will activate the Auto-Scaling Service. We can increase the amount of memory that
is being used by the application; we can increase the response time so that requests take longer to be processed
by the server; and we can increase the throughput by making a certain number of requests to
the server every second. We’re going to start by increasing the amount
of memory used. The demo allows us to set it to up to 87% of
the available memory, but for now we’ll just go with 192 megabytes…
right there. As you can see, the server has acknowledged
our request and is increasing the amount of memory it
is using. Next we will move over to the Auto-Scaling
Dashboard, which you can visit by clicking the link at
the top of the tab. As you can see we have already defined an
auto-scaling policy for this application. The application will scale up at 70% memory
usage, and it will scale down at 30% memory usage. If we click on the Metrics Statistics tab, we can see a graph of how much memory the
application is using over time. The auto-scaling service regularly measures
the average memory usage over certain time intervals, which we have set to 60 seconds. The graph also shows the Upper and Lower Thresholds
that have been set for the auto-scaling policy. When the service observes that the memory
has stayed above the upper threshold for 30 seconds or more, it will scale up the
application. As you can see here, the average memory usage
measured by the application has increased. Given a bit more time, the service will measure the memory again
and see that it has increased yet again, causing it to scale up. Right here, Bluemix has just alerted us to
the fact that our application has scaled up and it’s now running two instances. The graph lags behind just a little bit, but right here you can see that the memory
usage has been measured again, and it has definitely increased beyond our
upper threshold. Looking now at the Bluemix console, you can see that we are definitely running
on two instances instead of one. Now let’s head back to the demo and bring
our extra memory usage back down to zero. If we look at the graph again, we will see the memory usage go back down
to baseline levels after a couple of measurements. We’ve set a cooldown period of three minutes
before the application can scale out or in again, so we’re going to skip ahead a bit in the
video to show when that happens. And we’re back to a single instance. You can see in the graph that our memory usage
dropped shortly after we moved the slider back down, causing the application to scale in again
after the cooldown period had ended. Let’s try this on another metric. We’ll adjust the response time for each
incoming request. We could set it all the way up to 30 seconds,
but that’s a little excessive, so we’ll set it to three seconds of delay
for each request to the server. In order for Bluemix to recognize that the
response time has increased, our application makes a server request every
ten seconds, and the auto-scaling service measures that
delay. If you take a look at the auto-scaling policy,
you’ll see that I’ve adjusted it so that it now scales based on response time
instead of memory. Let’s head back to the Metrics Statistics
tab, so we can watch the response time increase
as well. You can see that it is the same style of graph
as before, with upper and lower thresholds based on what
we set for our auto-scaling policy. We’ll skip ahead. Here you can see that the auto-scaling service
has scaled up in response to the spike in response time, even before the graph displays its newest
data point, since the graph operates on fixed intervals
more than the application does. We’ll slide over to the Bluemix dashboard
and give it a quick refresh here, and there: we can see there are now two instances
running as we would expect. Let’s quickly head back over to the demo
application and bring the response time back down, and after the cooldown period has ended we’ll
see the application scale back in automatically. As we expected, here the application has scaled
back in after the average response time dropped back
to normal levels. Looking over at the dashboard, we can verify
that only one instance is running now. The values for memory and response time are
controlled by the server instead of by the browser. It’s possible that your browser will close
or refresh, setting all of these values back to zero, but the server will still be using extra memory
or delaying responses excessively. If this happens, you can use the Sync button
to get those values back. This syncing is tied to a specific instance
of the application; you can check which instance you are running
in the top-right corner of the page. Let’s say that we are currently using, let’s
see, 64 megabytes of memory and delaying each response by six seconds. Now if we were to go up and refresh the page, those values are going to get themselves set
back to zero, which is the page default. But by using the sync button, we can get those
values back, and proceed with what we were doing before. The last metric we can adjust is the throughput
to the server. Adjusting this slider will cause the browser
to send a certain number of HTTP requests to the server
every second, using web workers. Since web workers have slightly different
implementations across browsers, make sure that you are using an up-to-date
version of Chrome or Safari for the demo. If you are using Firefox, you will need to
make adjustments to your browser if you want to use more than 20 web workers. For this video, we’ll go all-out and issue
30 requests per second. Going back to the auto-scaling dashboard,
you can see that I’ve adjusted the policy again, and it now works on throughput. We will scale out on 20 requests per second,
and scale in under 5 requests per second. So let’s go back to the Metrics Statistics
dashboard and watch the throughput numbers increase
over time. Once more the application has scaled out, a little bit ahead of the graph displaying
our expected measurement of requests per second. If we go ahead and move back to the Bluemix dashboard, we can see that there are once again two instances running as we would expect. So now why don’t we go ahead and bring that
throughput back down so we stop sending all of those requests,
and once our cooldown period has ended, we should see the application scale back in. And again, the application has scaled down
in response to the decreased throughput after the cooldown period has ended. If we slide over to the Bluemix dashboard,
we can see once again only one instance is running. Looking at the top of the auto-scaling dashboard,
we can see the Scaling History of the application, which lists all of the events that occurred
which caused the application to scale out or in. As we observed, there are six events recorded
here, one for each instance of scale out and scale
in, along with more information on when they occurred
and how long they took. That should wrap it up for this video. This has been a look at the auto-scaling functionality
present in the Swift Enterprise Demo, demonstrating the capabilities of the Bluemix
Auto-Scaling service.

Leave a Reply

Your email address will not be published. Required fields are marked *