In modern web applications, it is of paramount importance to deal with latency correctly.  

Within an application, latency reveals itself at many different levels and with very different values. Computer latency at a human level is a good reference to understand the different timescales.

It is clear that  the dominant term, by large, is the network latency. This is something to bear in mind especially when using microservice architectures.

However, very few of us are familiar with the latency value of an internet call between two locations on Earth.

This post aims to shed some light on the subject by presenting some data collected on AWS infrastructure.

So, in the same way that the ubiquity of McDonald’s around the world has allowed economists to create the Big Mac Index, the ubiquity of AWS regions across the globe will let us create the AWS Latency Index to measure the performance of the internet calls.

Test description and results

The test consists of 4 web servers in 4 different AWS regions, Ireland, Oregon, Sydney and Sao Paulo, pinging each other once every minute. The servers return an empty response (http code 204). The latency of each call is stored in a database for later analysis.

The test was run in two different periods: from 2018-09-28 to 2018-10-23 and from 2019-02-23 to 2019-03-31.

Here’s the average value of the latency (in seconds) for each period:

origin	destination	Sep – Oct (2018)	Feb – Mar (2019)
oregon	ireland	0.269971	0.267397
ireland	oregon	0.271157	0.267159
oregon	sydney	0.309329	0.278629
sydney	oregon	0.309452	0.278496
ireland	saopaulo	0.397031	0.367805
saopaulo	ireland	0.397153	0.367862
oregon	saopaulo	0.403891	0.366153
saopaulo	oregon	0.405521	0.365982
ireland	sydney	0.550614	0.536054
sydney	ireland	0.550703	0.536064
saopaulo	sydney	0.672782	0.630039
sydney	saopaulo	0.67287	0.629908

A first look at the values reveals that, in most cases, the results are similar in both directions up to the order of units of milliseconds. This is good news, it would have been worrying had the results been different. From now on, we will consider just one of the directions for each par of regions.

The second thing to notice is that the values of the second period are consistently better, for instance, the improvement between Oregon and Sydney is about 31 ms and between Sao Paulo and Sydney is a whopping 43 ms.

To make it clearer, let’s present the data of each direction just for the second period:

origin	destination	Feb – Mar (2019)
oregon	ireland	0.267397
oregon	sydney	0.278629
ireland	saopaulo	0.367805
oregon	saopaulo	0.366153
ireland	sydney	0.536054
saopaulo	sydney	0.630039

The values vary from 267 ms between Oregon and Ireland up to 630 ms between Sao Paulo and Sydney. According to Computer latency at a human level, that is equivalent to 21 and 49 years, respectively. Just an eternity!

The following histogram provides a visual representation of the latency between Oregon and the other regions:

It is interesting to compare the above graph with the one corresponding to the first period:

Not only is the average latency better in the second period, but the values are more concentrated around the average value making a nice distribution graph.

Here are the graphs corresponding to the other regions:

If instead of histograms, we use time series analysis, we can get some interesting insights about the data. The below graph represents the values of latency between Ireland and Oregon during the sampled period (values are resampled into bins of 1 hour). The values over the 95% percentile are few and not very large, what is consistent with the histogram representation.

If we compare the above graph to the one corresponding to the first period, the difference is noticeable. The number of outliers is higher and their values greater.

After removing the values above the 95% percentile, the above graphs become:

The values of March are very well-behaved, with the median and the mean having nearly the same values. The same cannot be said of the values corresponding to October.

Latency index

Let’s focus on the results of March to calculate the latency index. We will define the latency index as the ratio between the theoretical value of the latency and the real one.

The theoretical value corresponds to the time it would take to cover the distance between two regions and back along the great circle connecting those regions and travelling at the speed of light.

origin	destination	latency	theoretical_time	theoretical/real
oregon	sydney	0.278629	0.082337	0.295508
ireland	sydney	0.536054	0.114806	0.214169
oregon	saopaulo	0.366153	0.072217	0.197231
oregon	ireland	0.267397	0.049941	0.186768
ireland	saopaulo	0.367805	0.062403	0.169664
saopaulo	sydney	0.630039	0.089302	0.14174

The values vary from nearly 30% between Oregon and Sydney to just 14% between Sao Paulo and Sydney.

Conclusion

The latency measurements obtained during the period of March 2019 are better behaved than those corresponding to October 2018. This may be down to either problems on AWS infrastructure back in October or problems on the Internet connectivity itself.

As to the latency index, it is a bit disappointing. The best result, for Oregon-Sydney, is just 30%. In other words, in the best case scenario the latency is more than 3 times the theoretical value.

In the case of Sao Paulo-Sydney is 7 times! Probably there is not direct cable between South America and Australia or the internet infrastructure in South America is not that great.

The application and the data collected can be found on AWS Index. That repository also contains 2 Jupyter Notebooks written in Python with all the details of the data analysis and calculations shown in this post. The notebooks can be executed online on https://nbviewer.jupyter.org/.