Visual Studio Online & Azure Load Testing – 502 error on site load

Posted Leave a commentPosted in Automations, Azure, Load Testing, Powershell, Testing

In a recent post I spoke about how I started using Azure Continuous Delivery on a personal project to deploy changes to my Azure instance on commit to my GitHub repository.  When changing over to this mechanism Azure gave me the option of load testing before production deployment.

Azure created everything needed and created a new web app for me as a staging environment.

The pipeline worked fine but when the load tests started firing they were not completing and 100% of the transactions failed with 502.

Failed load test results

I checked all my settings and realized Azure created everything required for the web app but didn’t create a database for the website.  Obviously, it does not copy the connection strings for the website as the database is a production instance, neither does it create a new database.

How to get the staging environment working

I want a database that automatically copies over from the production instance to a staging.  Azure has a feature called Sync Groups to will keep multiple databases in sync.  I tried using this however after speaking to a really friendly guy from Azure developer support named Yochanan.  It was determined for what I need this isn’t the right process.  Yochanan came up with the idea of using an Automation account to run a Powershell script to copy the production DB to the staging DB.

Azure Automations

Setting up the automation was really simple to do and the following blog post showed me how to use automations:

The Powershell

The Powershell script template used is here, I just updated the connection info:

$connectionName = “AzureRunAsConnection”
# Get the connection “AzureRunAsConnection ”
$servicePrincipalConnection=Get-AutomationConnection -Name $connectionName

“Logging in to Azure…”
Add-AzureRmAccount `
-ServicePrincipal `
-TenantId $servicePrincipalConnection.TenantId `
-ApplicationId $servicePrincipalConnection.ApplicationId `
-CertificateThumbprint $servicePrincipalConnection.CertificateThumbprint
catch {
if (!$servicePrincipalConnection)
$ErrorMessage = “Connection $connectionName not found.”
throw $ErrorMessage
} else{
Write-Error -Message $_.Exception
throw $_.Exception

“Removing old copy…”
Remove-AzureRmSqlDatabase -ResourceGroupName “AutomationForCase” -ServerName “yocrsrvforcase” -DatabaseName “ProdDB_Copy” -Force

“Start Copy… Please wait … ”
New-AzureRmSqlDatabaseCopy -ResourceGroupName “AutomationForCase” `
-ServerName “yocrsrvforcase” `
-DatabaseName “ProdDB” `
-CopyResourceGroupName “AutomationForCase” `
-CopyServerName “yocrsrvforcase” `
-CopyDatabaseName “ProdDB_Copy”

” !Done! ”

The automation is scheduled to run every 24 hours and the process works well.  It took about 2 minutes to delete the old database and then copy the new one.

Next Step – Run the load test again

After triggering a new build the deployment worked successfully and the load testing worked perfectly now the website has its database.

Passing load test results

Here are the load charts

Load test chart

The confidence in the website and the cloud infrastructure is even higher now after getting this working.

The outcomes

  • Load testing on the website that simulates 25 user per second load
  • A backup of the production instance every 24 hours
  • Had a try at Azure Automations

This is a great learning experience and Azure has made it so easy to complete this task.  Currently I am looking into Selenium test automation on visual studio online and will be writing a blog about that next.

Happy load testing!

Getting started with Azure Continuous Delivery

Posted 1 CommentPosted in Asp.Net, Azure, Load Testing, Testing

I have used Azure now for a few years to host a personal project for a family run company.  The process has always been really simple, check into Github then Azure automatically picks up the changes and deploys directly to the cloud.

If its so good why did i change this?

I’m a sucker for new technology and when I was in Azure earlier I noticed a new option under my Web app called Continuous Delivery.

This is a preview feature but I knew if it didn’t work then I could easily change it back.  This is a great new feature of Azure as you can now run unit tests as part of the really simple  build process.  So found out quite early that you can only have one deployment configuration active so I removed the old deployment step and continued with the Continuous Delivery setup.  Im not going to go into the steps to set up as the following tutorial was what i followed –

What are my thoughts on this and will I keep using this?

Short answer yes the process is really good and honestly gives me the confidence in regression testing as its running my unit tests.

The first 4 builds actually failed due to issues with my code and how I didn’t have the db context mocked for an audit class that I have built for my website.  In addition i selected the option for the VS online build and release to create a staging environment for deployment.  This is great as the unit tests are run in an isolated environment with no database.


Then the load testing aspect this is a really useful feature however took a little while to find in visual studio online.  Under the Test menu us a sub item for Load Test.  This has all the load test runs and also the info, currently all mine are throwing a 502 so need to get the resolved, but this is on the staging instance!

Next Steps

So this is a great feature and i think everyone should try it out.

Next for me is to try and get Selenium running with this to give a proper CI pipeline that not only tests the controllers and models but also the front end.