This article will show you how to test your network latency to different Azure regions so you can make the best decision possible when choosing where to deploy your resources

Brandon Olin

Brandon is a Cloud Architect and veteran Systems Engineer with a penchant for PowerShell, DevOps processes, and open-source software. You can reach Brandon at devblackops.io or on Twitter @devblackops.

Why you should care about latency ^

The distance and speed between you and services hosted in Azure can have a profound impact on performance and responsiveness. The laws of physics bind us, so in general, the closer you are physically to an Azure region, the lower the latency. This is not a hard-and-fast rule though. The internet is a messy place, and network traffic may not take the shortest route to get the lowest latency. You may be surprised to find that what you thought was the best Azure region to host your services in—because it was physically the closest—may have higher latency than another farther away.

But how do you determine what the lowest-latency Azure region is? Funnily enough, Microsoft does not provide a publicly discoverable service to which we can simply ping and measure the response time. We'll have to come up with our own methods to test each region.

The simplest way to test latency to a region is to download a small file from Azure Blob storage and measure the time difference between the start of the operation and the end.

Let's get started ^

To get started, let's go ahead and log in to Azure and create a resource group that will hold our storage account. We're going to use the westus Azure region for this. If you would like to test another Azure region, simply substitute your desired region name below. To make things easy, here are the currently available Azure regions around the globe.

We'll need to create a storage account to perform our test. In Azure, storage accounts require public DNS names, so we need to come up with a globally unique name. Let's create a random identifier using the first eight characters of a GUID.

Now we'll go on to creating our storage account.

We're using locally redundant storage because in the event of an Azure region failure, we don't want our storage account to fail over to another region, as that would defeat the purpose of the region-specific latency test.

Now we need to create a test file for uploading. For this, we'll just use some dummy text. To gather our latency metric, we're going to measure the time it takes to download this file.

Now let's move on to creating a storage container and uploading our test file. To do this, we'll need the storage context from the newly created storage account. We'll also set the permissions to Blob. This will grant anonymous read access to a blob but won't allow read access to the container itself. After uploading this, we'll also need to get the URI of the resultant blob.

Great! We now have a storage account in the westus Azure region and some test data to work with. Now let's measure the time it takes to download this file.

The above section is a long one so let's break it down.

Simply downloading the file once wouldn't give us a representative result. The internet is a crazy place, and we don't want an errant slow result throwing off our measurement. To smooth out the results, we'll perform 100 iterations and use the [System.Diagnostics.Stopwatch] .NET class to measure the time it took. We could have used Measure-Command, but we want an accurate measurement, and using raw .NET classes will perform better than PowerShell cmdlets.

We create an ArrayList collection to hold our raw results and a hashtable called $regionResult to hold our final region results. We're not using your normal PowerShell array for our raw results, since again, we want an accurate measurement, and appending to PowerShell arrays is slow. Using the raw .NET collection classes is much faster.

We now enter our for loop. Notice that before entering the loop, we've disabled the progress bar. Invoke-WebRequest has a bad reputation for being slow because by default, it displays a progress bar when executing a request to show the amount of data received and sent. It calculates the size and time remaining, and by doing that calculation, it slows down the operation substantially. We don't want that calculation throwing off our results, so we'll disable it.

We now start the stopwatch, use Invoke-WebRequest to download the file, then stop the stopwatch. Notice we also redirected the output of Invoke-WebRequest to $null with the redirection operator >. We don't really care about the output of Invoke-WebRequest, just the time it took.

Now we add the elapsed milliseconds to our $rawResult variable and reset the stopwatch for the next round in the loop.

Once we've completed all 100 iterations, we'll be a good citizen and reset the $ProgressPreference variable to what it was set to originally.

Using the raw results we've collected, we now calculate the average, minimum, and maximum times and add them to our region result.

Finally, we'll cast the hashtable to a PSCustomObject to display it better.

Result ^

Let's look at our results for the westus region.

Final region latency results

Final region latency results

Not too bad—it's about 40ms to westus. I wonder what the latency would be to the France Central region.

I'll leave that as an exercise for the reader.

Join the 4sysops PowerShell group!

Your question was not answered? Ask in the forum!

1+
Share
1 Comment
  1. Joe 11 months ago

    Great work! salute!

    0

Leave a reply

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

*

© 4sysops 2006 - 2020

CONTACT US

Please ask IT administration questions in the forums. Any other messages are welcome.

Sending

Log in with your credentials

or    

Forgot your details?

Create Account