Azure Overseas Multi-region Latency Disclosure: Performance Speed Measurement of Computer Rooms in Asia Pacific, North America and Europe
One of the biggest headaches for architects and O & M companies doing overseas business is
Network delay
.
When you want to deploy your business to the Microsoft cloud (Azure), faced with its dozens of data centers around the world, you may fall into choice anxiety:
"My users are in Europe and the United States, in the end the beauty of the West or the United States East?"
"How many milliseconds is the difference between Singapore and Hong Kong in the Asia-Pacific region?"
"How long does it take to transfer data across the Atlantic or across the Pacific?"
Many candidates are based on "feeling" or geographical distance. However, the routing of the Internet is not as simple as pulling a straight line. How many public network exchange points it bypasses, whether it takes submarine optical cables or land optical cables, and the extent to which Microsoft's backbone network (Global Network) covers will directly determine your final business delay.
In order to explain this problem thoroughly and clearly, this article has been compiled.
Asia Pacific, North America, Europe
The latest network performance and speed measurement data of the three major sea-going areas are all used without the theory of virtual.
Real Round Trip Time (RTT) and Real Business Scenarios
Speak up and completely expose Azure's overseas multi-regional delay cards.
1. pick up the bottom line first: what makes Azure's global backbone network?
Before looking at the specific speed measurement data, we must first understand a major premise:
You transfer data between two computer rooms inside Azure. Is the traffic going through the public network?
The answer is:
By default, the public network is not used.
Microsoft has one of the largest private backbone networks in the world (Microsoft Global Network). When you send data from Azure's "East Asia (Hong Kong)" computer room to the "US West (California)" computer room, the traffic comes out of the Hong Kong computer room and immediately enters Microsoft's private optical cable or leased dedicated optical fiber. Along the way, it passes through Microsoft's self-built Edge POPs (Edge POPs) and is directly pulled to the west coast of the United States.
The benefit of this "private highway" is
Extremely stable
. The public network is like an ordinary road in the morning and evening peak, which may shake at any time due to congestion at a certain node. The backbone network of Azure is like a closed high-speed VIP pass, with delays basically in a straight line and few fluctuations.
But here’s the problem:
No matter how fast the highway is, it is faster than the physical limit (the speed of light in glass fiber is about 200000 kilometers per second).
This means that the geographical distance still determines the lower limit of the delay.
2. Asia-Pacific Market Speed: A Golden Springboard for Southeast Asia and East Asia
The Asia-Pacific region is the first stop for companies going out to sea. We focus on four core computer rooms:
East Asia (Hong Kong), Southeast Asia (Singapore), East Japan (Tokyo) and Central Korea (Seoul)
.
1. Asia-Pacific Internal Interconnection Latency (unit: ms)
The following is the true latency performance between these core data centers and from major network nodes in mainland China to these data centers:
Origin/Destination
East Asia (Hong Kong)
Southeast
Asia (Singapore)
East Japan (Tokyo)
Central Korea (Seoul)
East Asia (Hong Kong)
0 - 2
30 - 35
45 - 50
40 - 45
Southeast Asia (Singapore)
32
0 - 2
65 - 72
80 - 85
East Japan (Tokyo)
forty-eight
Sixty-eight
0 - 2
25 - 30
Guangdong, China (public network into the sea)
10 - 15
35 - 45
55 - 65
60 - 70
Shanghai, China (public network into the sea)
25 - 30
45 - 55
30 - 35
35 - 40
2. Depth Profiling and Pit Avoidance Guide
Hong Kong vs Singapore: If your business target is the whole of Southeast Asia (Indonesia, Vietnam, Thailand, Philippines, etc.), close your eyes and choose Singapore (Southeast Asia). The quality of public network routes from Singapore to neighboring countries is extremely high, and the delay from Singapore to Hong Kong is only about 30ms. If your main customer is in mainland China plus radiation Hong Kong, Macao and Taiwan, Hong Kong (East Asia) is preferred.
The wonderful relationship between Japan and South Korea nodes: the delay from Tokyo to Seoul is very low, only about 25ms, which can basically be regarded as half of the same city backup. If your business is games or real-time audio and video, Japan and South Korea can even do cross-regional service.
The "big pit" of mainland visit: please note that although the physical distance from Shanghai to Tokyo is farther than that to Hong Kong, due to the international optical cable trend of operators such as China Telecom and China Unicom, the delay from Shanghai to Tokyo (30-35ms) is often the same as that to Hong Kong. The delay is even, even occasionally lower. However, do not deploy mainland-based businesses directly in Tokyo, because the public network in Japan is occasionally severely disturbed by submarine cable earthquakes or international export congestion at night peak, and its stability is far less than that of land/offshore optical cables to Hong Kong.
3. North American Market Tachometer: A Game Across East and West Coasts
The U.S. market is the ultimate battleground for many offshore companies (especially SaaS, e-commerce, online earning, and gaming). Azure has a large number of computer rooms in the United States, the core of which is:
US East (Virginia), US East 2, US West (California), US West 2 (Washington) and US Central (Iowa)
.
1. North American internal and transoceanic latency (unit: millisecond ms)
Origin/Destination
West America (California)
West 2 (Washington)
US-China (Iowa)
US East (Virginia)
West America (California)
0 - 2
15 - 20
40 - 45
65 - 70
US East (Virginia)
Sixty-eight
seventy-five
30 - 35
0 - 2
East Asia (Hong Kong)
145 - 155
150 - 160
185 - 195
210 - 225
East Japan (Tokyo)
105 - 115
95 - 105
140-
150
160 - 170
2. Depth Profiling and Pit Avoidance Guide
Trans-Pacific "line of life and death": look through this form, and you will understand why "US West" is the bridgehead for the Asia-Pacific to go to sea. From Tokyo across the Pacific to US West 2 (Washington State), the delay can run within 100ms (about 95ms)! And if you start from Hong Kong to the United States, about 150ms. However, if your data is to be pulled all the way from Hong Kong to the US East (Virginia), the delay will directly soar to more than 210ms. With a latency of more than 200ms, any unoptimized TCP handshake or database cross-regional query will be as slow as a turtle.
Choice of East and West Coast in the United States: U.S. public network users have a relatively high tolerance for delay. If your users are evenly distributed across the United States, the beauty pageant (Iowa) is the most worry-free, reaching both the east and west sides within 40ms. If it is heavily dependent on European connectivity, pageant East; if it is heavily dependent on Asian backflow, pageant West.
4. European Market Tachometer: Frankfurt and Amsterdam at the core
Europe's Internet ecosystem is very mature, and the quality of interconnection between major computer rooms is among the best in the world. Azure's two core "Big Mac" rooms in Europe are:
Western Europe (Amsterdam, Netherlands) and Northern Europe (Dublin, Ireland)
In addition, there are extremely important in recent years.
Central Germany (Frankfurt)
.
1. Intra-European and transatlantic latency (in milliseconds ms)
Origin/Destination
Western Europe (Netherlands)
Northern Europe (Ireland)
Central Germany (Frankfurt)
US East (Virginia)
Western Europe (Netherlands)
0 - 2
12 - 15
6 - 8
70 - 75
Northern Europe (Ireland)
14
0 - 2
18 - 22
65 - 70
Central Germany
seven
Twenty
0 - 2
75 - 80
Southeast Asia (Singapore)
150 - 160
165 - 175
145 - 155
-
2. Depth Profiling and Pit Avoidance Guide
Inside Europe: Fast as a LAN. Thanks to the dense terrestrial fiber optic cable network in continental Europe, the latency from Western Europe (the Netherlands) to Central Germany (Frankfurt) is only 6-8 milliseconds. This means that if you leave the web server in the Netherlands and the database in Frankfurt, you will not feel the negative impact of the delay at the business level.
The transatlantic super channel: the delay from the east coast of the United States (Virginia) to Europe (Ireland/Netherlands) is extremely impressive, only taking 65-75ms. This delay is even lower than some public network delays from Hong Kong, China to Beijing, China. Therefore, the integration of Europe and the United States (Europe and the United States with the service, cross-border data synchronization) in the architecture is very easy to achieve, both sides to do real-time data synchronization (Replication) pressure is much less than Asia to the United States.
5.
Actual combat landing: the architecture selection scheme of the three classic scenarios.
After reading the cards of Asia-Pacific, North America and Europe, how should we design the architecture when we actually land overseas business? The following are the three most typical actual combat scenarios:
Scenario 1: Real-time gaming/audio and video services across the globe
Pain point: Players are globally distributed, require very low latency (preferably less than 100ms), and need to be online in a server.
Architectural solution: Don't put all the servers in one place. Bring in public traffic with Azure's Anycast IP (Global Starter/Azure Front Door). The game room/battle node (Battle Server) distributed deployment in Singapore (Asia Pacific), the United States West 2 (North America), Western Europe (Europe). Core data is asynchronously synchronized back to the main database (e. g., located in the United States and China) using the Microsoft backbone. Players access nearby to ensure a local delay of 25ms during the battle, while cross-border data exchange is handed over to Microsoft's backbone network to run.
Scenario 2: Cross-border e-commerce/independent station going to sea
Pain point: if the website opens slowly for one second, the conversion rate will drop by 10%. Customers are mainly in the United States and Europe.
Architecture Solution: It is recommended to deploy the main station in the East of the United States (Virginia). Why? Because the American East is a perfect "pendulum point"-it's 70ms to the American West and 70ms to Europe. Work with Azure Front Door (with CDN acceleration) to push static resources and caches to edge nodes across Europe and the United States. In this way, customers in Europe and the United States open web pages within 10-30ms (hitting the edge cache), and when they need to go back to the United States to write the database, the 70ms delay between Europe and the United States is completely within the user's tolerance range.
Scenario 3: Office/ERP Cross-border Synchronization of Asia-Pacific Multinational Enterprises
Pain point: The domestic headquarters is in Shenzhen/Shanghai, there are factories in Southeast Asia, and there are sales branches in the United States. Visiting the same ERP system often gets stuck.
Architecture Solution: Set up Asia-Pacific Core Node in Hong Kong (East Asia) or Singapore. As domestic employees have cross-border public network compliance and jitter problems when visiting overseas, it is recommended that enterprises use Azure ExpressRoute (dedicated line) to access Azure Hong Kong computer room in mainland China to achieve zero jitter. Connections from Hong Kong to the US and Singapore to Europe, purchase Global VNet Peering directly within Azure. In this way, all cross-border traffic is locked on Microsoft's private highway, completely bid farewell to the system Catton caused by public network packet loss.
6. Summary
The essence of network delay is a comprehensive reflection of physical distance and fiber direction. In the global network ecology of Azure, we have summarized three hard laws:
Trans-Pacific (Asia-US) very far (110ms-160ms), trans-Atlantic (US-Europe) very close (65ms-75ms). Crossing
Eurasia (Singapore-Europe) is in the middle (around 150ms).
Make good use of regional centers. Singapore in Asia Pacific, East/West in North America, and Holland/Frankfurt in Europe are the "super nodes" with the most concentrated network resources and the most abundant submarine cable exports. It is usually not a big mistake to choose them first.
The distance cannot be changed, but the path can be changed. Try to let traffic enter the Azure internal network (use VNet Peering, Front Door) to avoid long streaking on the chaotic international public network (Public Internet).
Find out the base number of these speedometers, and then design your overseas multi-regional architecture, you will naturally have the confidence in your heart.
