Редактиране

Споделяне чрез

Test network latency between Azure VMs

  • Статия

This article describes how to test network latency between Azure virtual machines (VMs) by using the publicly available tools Latte for Windows or SockPerf for Linux.

For the most accurate results, you should measure VM network latency with a tool that's designed for the task and excludes other types of latency, such as application latency. Latte and SockPerf provide the most relevant network latency results by focusing on Transmission Control Protocol (TCP) and User Datagram Protocol (UDP) traffic. Most applications use these protocols, and this traffic has the largest effect on application performance.

Many other common network latency test tools, such as Ping, don't measure TCP or UDP traffic. Tools like Ping use Internet Control Message Protocol (ICMP), which applications don't use. ICMP traffic can be treated differently from application traffic and doesn't directly affect application performance. ICMP test results don't directly apply to workloads that use TCP and UDP.

Latte and SockPerf measure only TCP or UDP payload delivery times. These tools use the following approach to measure network latency between two physical or virtual computers:

  1. Create a two-way communication channel between the computers by designating one as sender and one as receiver.
  2. Send and receive packets in both directions and measure the round-trip time (RTT).

Tips and best practices to optimize network latency

To optimize VMs for network latency, observe the following recommendations when you create the VMs:

Use the following best practices to test and analyze network latency:

  1. As soon as you finish deploying, configuring, and optimizing network VMs, take baseline network latency measurements between deployed VMs to establish benchmarks.

  2. Test the effects on network latency of changing any of the following components:

    • Operating system (OS) or network stack software, including configuration changes.
    • VM deployment methods, such as deploying to an availability zone or proximity placement group (PPG).
    • VM properties, such as Accelerated Networking or size changes.
    • Virtual network configuration, such as routing or filtering changes.

  3. Always compare new test results to the baseline or to the latest test results before controlled changes.

  4. Repeat tests whenever you observe or deploy changes.

Test VMs with Latte or SockPerf

Use the following procedures to install and test network latency with Latte for Windows or SockPerf for Linux.

Install Latte and configure VMs

  1. Download the latest version of latte.exe to both VMs and put it in a separate folder such as c:/tools.

  2. On the receiver VM, create a Windows Defender Firewall allow rule to allow the Latte traffic to arrive. It's easier to allow the latte.exe program by name than to allow specific inbound TCP ports. In the command, replace the <path> placeholder with the path you downloaded latte.exe to, such as c:\tools\.

    netsh advfirewall firewall add rule program=<path>latte.exe name="Latte" protocol=any dir=in action=allow enable=yes profile=ANY

Run Latte on the VMs

Run latte.exe from the Windows command line, not from PowerShell.

  1. On the receiver VM, run the following command, replacing the <receiver IP address>, <port>, and <iterations> placeholders with your own values.

    latte -a <receiver IP address>:<port> -i <iterations>
    • Around 65,000 iterations are enough to return representative results.
    • Any available port number is fine.

    The following example shows the command for a VM with an IP address of 10.0.0.4:

    latte -a 10.0.0.4:5005 -i 65100

  2. On the sender VM, run the same command as on the receiver, except with -c added to indicate the client or sender VM. Again, replace the <receiver IP address>, <port>, and <iterations> placeholders with your own values.

    latte -c -a <receiver IP address>:<port> -i <iterations>

    For example:

    latte -c -a 10.0.0.4:5005 -i 65100

  3. Wait for the results. Depending on how far apart the VMs are, the test could take a few minutes to finish. Consider starting with fewer iterations to test for success before running longer tests.

Next steps