 Hi, my name is Charles Sterling. I'm a senior program manager on the Visual Studio team, and I can't believe it's been a year since I did a cloud-based load testing video for Connect. Since that year, we've done a tremendous amount of work for you guys. Let's take a look at the list. So one of the top requests that we've got is to be able to collect performance counters while you're running a cloud-based load test. And we've done that. By integration with application insights, we can actually give you those performance counters while you're running your load test. A lot of requests are making it simpler to use. So rather than actually opening up Visual Studio and starting a new test project, we've actually give you web-based authoring. In addition to the web-based authoring and Visual Studio team services, we actually now give you a web-based authoring experience that's even richer with better diagnostics in the Azure portal. And I'm going to show you that. DevOps integration. For you, DevOps shops, being able to integrate a load test as part of your continuous integration build or your release pipeline is now super simple. I'm going to show you that one too. Scalable. We've done a ton of work on making the service more scalable. So we now actually support up to 100 cores. And you can run that in 10 parallel sessions. So you actually get up to 1,000 cores across one run. We'll let you run it up to 72 hours now. And you can run those load tests from 10 different geographies. So you can actually run it from the West US, East US, Asia, Europe, et cetera. And finally, the number one request that we get on a regular basis, I want to build a load test. My application running behind a firewall with the cloud-based load testing. So what we do now is we actually will give you a trusted IP address. And we'll say, this is the IP address that our load test service is coming from. And we're going to update the service to actually integrate with Azure VNet. And we're going to integrate that back with the Visual Studio IDE. Speaking of the Visual Studio IDE, we're actually going to refresh the entire wizard right after the beginning of the year. So expect to see that right after Christmas. So lots and lots of new value. I want to show it to you. So let's go ahead and start with a demo of the new web authoring experience in Azure and that DevOps release pipeline integration. I wanted to show you two demos of load testing, of new features that we've added. The first one is the new easy to use web-based authoring experience in the Azure portal. You can see that I'm in the Azure portal and I've actually pinned a bunch of tiles for my application to the home page. One of them is for my parts and limited app. Now what's new is if you go to the tools menu for this web app, you'll actually see that right here there is a brand new option called Performance Test. I want to show you the new authoring experience. So let's click on New. And you'll see right off the bat, it's actually pulled in the root of my URL. That's pretty cool. If I want to go ahead and use a different website entirely or if I wanted to take a look at a view, for instance, this is an MVC application, I want to take a look at the home view, I can go ahead and overwrite that. I do recommend that you actually change the name from the defaults because these tests are visible both in Visual Studio and Azure. So if I want to go ahead and do correlation or trend or comparisons from a on-premise run versus a cloud-based run, I can do that from Visual Studio. But you're going to need to have a name for that. So let's call this one Sprint 3. As I mentioned, I can actually specify 10 geographies around the planet where I run this from. I'm going to choose East US 2. And a user load of 250, we decided it was my development team building this app that we wanted to have be able to support at least 250 users for sub-5 second response times. So let's go ahead and leave that at five seconds. Five minutes is a great duration for this run. And we're going to go ahead and kick that off. And you can see that this one is now queued. This one is in progress. So let's take a look at this actually as it's running. And you'll see that I've got three failures over 70,000 requests. That's actually not too bad. In taking a look at my request per second, you can see after it's getting warmed up, we're running at three seconds with a request per second of 324 in this case. That is great performance. I'm really happy with the team. They've really stepped it up. It looks like we've got some issues when we start. So we'll work on that. We need to actually do some buffering and some caching in this application. It looks like some front loading. But overall, you can see that this is going to give me the data to figure out whether or not I'm actually meeting my SLAs. And you can see that it's still in progress. That run is still going. And if we take a look at the one that we just started a couple of minutes ago, once again, you're going to see that is now going to go out and start doing this run. So you can go ahead and do long running tests and take a look at them in real time. And here's one that's completed. So you'll see in this case, I had zero failures, but I'm still seeing that shark fin right off the bat. So again, we've got some issues. So that's the first demo I wanted to talk to you about was that new web authoring experience with diagnostics data that's going to easily show you if you've got issues. Again, kind of the smoking gun, if you will. Now, the second demo I want to show you was how easy is it to actually integrate load testing into your DevOps pipelines. What you see in front of you is a build that me and Corey Feller created a couple of weeks ago in our DevOps webinar. If you've got time, I do recommend you guys watching it. And you'll see that for our CI build, we are building our solution. We're publishing our artifacts for our release pipeline. And then we're deploying it into a development slot so our developers can take a look at it. What we found is often the deployment will work just fine, but the web app won't be available because of some problem, something that was missing. I want to show you how you can actually easily detect that. So I'm going to go ahead and add a build step for this build, go to test, and we're going to choose the one that's called a quick load test or quick performance test. And what it's asking is, for that remote agent, where should it publish the results back to? I want to go ahead and publish them into this account, which kind of makes sense. And what URL do we want to test? In this case, we would probably take a look at whatever was being deployed here. So we are deploying the web app, www.awesome2. So we want to go ahead and do hdp colon slash slash slash www.awesome2.azurewebsites.net. So it's going to go ahead and run that quick performance test against there. Again, what we're mostly interested in is, did it come up? Are we getting 404s or 500 errors saying that it's not even running? And let's call this one available one. At this point, if it's not available, we probably do not want to continue on error. So we're going to leave that checked, but we do want to enable that. So easily or an easy way for you determine whether or not your web app deployments are actually successful is by adding a quick performance test. In addition, you will probably want to go ahead and do a formal load test or performance test to see if you're meeting your SLAs like I showed you before. Let's go ahead and go into the release hub for Visual Studio Team Services Release Management and edit the web camps release pipeline. That's the one that me and Corey created. And you'll see that it's actually got the three canonical environments. You're dev, you're staging, and you're prod. In staging, we want to know if we're hitting our SLAs. So we're going to go ahead and add the task, go back to test, go ahead and select a full blown load test. And the difference is instead of specifying just a simple URL, we're going to go through multiple URLs defined in a web test. And I can do additional things like use plugins, do data binding, et cetera. So same question right off the bat. Where do we want to publish those results? And I want to publish them back to this Visual Studio Online account. And it's asking me, where are my local test settings file? Now, in this case, I have actually published those as part of that published tasks that you saw earlier. So I'm going to go to my drops. I'm going to go to my version control or my build output. I'm going to find the local test settings. And this is actually going to do things like say, should we run a batch on startup? What are we data binding to? So that's what the local test settings is going to reference. Then it's saying, where did you put your web tests? And once again, it was published as part of that drop. So I don't have to remember to type it all in. I just reference it. And it's asking me, what is the load test file that we want to run? You might have multiples in that same directory. I recommend you do not call it load test one. But in this case, I actually called it home page. And in this case, I probably want to go ahead and say continue on error. If I'm not meeting my SLAs, I want to be notified about it. But I probably do want to go ahead. And if I have an approval stage to go into prod, let the approval stage actually get notified. So let's recap. I can use quick load tests to go out and take a look at whether or not my CI deployments were successful. And I could do a full load test into my staging or performance environment to see if I'm hitting my SLAs. Oh, I hope you enjoyed the demo. As you can see, we've done a lot of work on the cloud-based load testing. Just walking through the list one more time. Integration with application insights. Easy to use web-based authoring with diagnostics. DevOps integration with a simple adding of a task, integrating load tests into your releases and into your builds. Scalable, hunter cores, 10 locations, 72 hours, 10 parallel runs, that's a lot of scale. And finally, load testing behind a firewall using IP addresses and soon with VNAT integration. One thing I didn't talk about is if you haven't checked the prices, we actually have made it much more affordable for you to get started with cloud-based load testing. I'm Charles Sterling and thank you very much for joining me.