Elastic Compute Service:Network performance FAQ

Test instance packet forwarding capability

For general packet forwarding test methods, see Network performance test methods. For the recommended packet forwarding test method for g7, c7, and r7 instances, see Use Pktgen to test network performance.

Packet loss rate for cross-region communication

For internet communication between ECS instances in different regions, the P99 packet loss rate per hour is less than 0.0001%.

Intra-zone network latency

Internal communication between ECS instances in the same zone of a region has the lowest latency. The P99 one-way latency between instances in the same zone is less than 180 microseconds (μs).

View the latency between different zones.

Connection performance for instances without specified limits

Unstable performance in UDP or TCP tests

Many factors can affect the results of a network performance test on an ECS instance, including common tuning methods such as Non-Uniform Memory Access (NUMA) topology adaptation, binding tasks to vCPUs, and binding interrupts to vCPUs.

For example, during a single-stream TCP bandwidth test, if the receiving task (such as a netserver process) and the network interface card (NIC) receive queue interrupt are bound to the same vCPU, the NIC triggers an interrupt that disrupts the receiving task when it receives a data frame. Frequent disruptions can cause unexpected test results. To resolve this issue, bind the receiving task and the NIC receive queue interrupt to different vCPUs. This approach leverages multiple vCPUs for better test results.

Public bandwidth fluctuation

The PayByBandwidth billing method guarantees the bandwidth value that you set. This bandwidth value is stable and does not fluctuate.

For the Pay-by-traffic billing method, the peak inbound and outbound bandwidths are unguaranteed upper limits. When resource contention occurs, the peak bandwidth may be limited. If your services require guaranteed bandwidth, use the PayByBandwidth billing method. For more information, see Network bandwidth.

Inbound traffic on new instances

This traffic is generated by Address Resolution Protocol (ARP) broadcast packets. Each ECS instance is assigned to a large network segment. In the same network segment, your new ECS instance receives a request message whenever an ECS instance sends an ARP broadcast to the gateway. However, your ECS instance does not respond if the request is not for its IP address.

Bandwidth discrepancy between Cloud Monitor and ECS console

An ECS instance can act as a backend server for a Server Load Balancer (SLB) instance and use the Layer-7 HTTP forwarding model. In this model, the SLB instance forwards client requests to the ECS instance. The ECS instance then responds to the client using its public bandwidth. The bandwidth for this response is not displayed in the ECS console because it is metered as part of the SLB instance's outbound traffic. This causes the discrepancy between the bandwidth shown in Cloud Monitor and the ECS console.

Outbound traffic from stopped instances

• Symptom: In the Anti-DDoS Origin Basic console, an ECS instance has a Cleaning status, but the instance itself is Stopped. However, hourly fees are still incurred for its pay-by-traffic public bandwidth.

• Cause: CC protection is enabled for the ECS instance. The security mechanism actively sends probe packets to detect attack sources, which can generate significant outbound traffic.

• Solution: Disable CC protection. For more information, see Configure CC protection.