All Products
Search
Document Center

Tair (Redis® OSS-Compatible):Test the synchronization latency for Global Distributed Cache

Last Updated:Dec 12, 2025

Global Distributed Cache for Tair provides high performance and low latency. This topic describes how to test the synchronization latency between child instances in different regions.

Feature overview

Global Distributed Cache for Tair is an active geo-redundancy database system developed in-house by Alibaba Cloud and is based on Tair (Redis OSS-compatible). Global Distributed Cache supports business scenarios where multiple sites in different regions provide services simultaneously. It helps enterprises quickly replicate Alibaba's active geo-redundancy architecture. For more information, see Global Distributed Cache.

Test environment

Database instance setup

Test environment context

Description

Child instance architecture

Standard architecture without a cluster enabled. For more information, see Standard Architecture.

Note

For a cluster architecture, the overall cluster performance is at least n times that of the standard architecture when requested keys are evenly distributed.

Child instance type

The instance type has little effect on the test results. A 1 GB master-replica instance is sufficient to complete the test. For more information, see Memory-optimized (Standard Architecture).

Child instance version

The instance version typically has little effect on the test.

Client setup

Test environment

Description

Device to deploy the stress testing tool

An ECS instance with a Python 3 environment installed. For more information, see Instance family.

Region and zone

You need to prepare two ECS instances. Each ECS instance must be in the same region and zone as the corresponding database child instance (source and destination).

Network

The same virtual private cloud (VPC) as the database child instance, connected through the VPC.

Tool setup

The test tool is tairgdn-latencytest. This program calculates latency by calculating the difference between the timestamp when a key is read on the destination instance and the timestamp stored in the key's value (which represents the write time on the source).

Note

The value of a key is the timestamp when data is written to the key on the source instance.

Test example

Important
  • Clear the database before each test. Perform tests only on a test instance.

  • You can change the write QPS by adjusting the number of connections and the pipeline depth for write operations. Do not exceed the write QPS limit. For more information, see Global Distributed Cache.

  • Before testing, add the IP address of the ECS instance to the whitelist of the child instance in the corresponding region. For more information, see Set an IP address whitelist.

The following steps show how to test the synchronization latency for data transfer from a child instance in the China (Beijing) region to a child instance in the China (Shenzhen) region. You can use a similar method to test the latency between child instances in other regions.

Synchronization latency test environment

image
  1. Log on to the ECS instance in the China (Shenzhen) region and install tairgdn-latencytest:

    pip install tairgdn-latencytest
  2. Run the synchronization test command:

    tairgdn-latencytest read -h {host} -p {port} -u {username} -a {password} -n {keynumber}
    Note

    The command reads keys from the child instance in the China (Shenzhen) region. The command waits for and reads keys synchronized from the child instance in the China (Beijing) region. The command then calculates the latency by calculating the difference between the time a key is read and the value of the key.

    Parameter

    Description

    {host}

    The private endpoint of the child instance. For more information about how to obtain the endpoint, see View endpoints.

    {port}

    The port of the child instance in the China (Shenzhen) region. The default value is 6379.

    {password}

    The password of the child instance in the China (Shenzhen) region.

    Note

    If you use a newly created account, the password must be in the <user>:<password> format. For example, if the username is admin and the password is Rp829dlwa, the password to connect to Redis is admin:Rp829dlwa.

    {keynumber}

    The number of keys to read.

  3. Log on to the ECS instance in the China (Beijing) region and install tairgdn-latencytest:

    pip install tairgdn-latencytest
  4. Run the synchronization test command:

    tairgdn-latencytest write -h {host} -p {port} -u {username} -a {password} -n {keynumber} -P 16 -c 16
    Note

    The program continuously creates keys and writes data to the child instance in the China (Beijing) region. The program uses incremental integers for the key names and the UNIX timestamps of the write operations for the key values.

    Parameter

    Description

    {host}

    The private endpoint of the child instance in the China (Beijing) region. For more information about how to obtain the endpoint, see View endpoints.

    {port}

    The port of the child instance in the China (Beijing) region. The default value is 6379.

    {password}

    The password of the child instance in the China (Beijing) region.

    Note

    If you use a newly created account, the password must be in the <user>:<password> format. For example, if the username is admin and the password is Rp829dlwa, the password to connect to Redis is admin:Rp829dlwa.

    {keynumber}

    The number of keys to write. This must be the same as the value specified in Step 2.

  5. Wait for the program on the ECS instance in the China (Shenzhen) region to finish. The program prints the synchronization latency from the child instance in the China (Beijing) region to the child instance in the China (Shenzhen) region.

Note

If the network link is long, such as for synchronization between regions on different continents, the round-trip time (RTT) becomes the main factor that affects synchronization latency. Synchronization latency is typically between a few hundred milliseconds and several seconds, depending on carrier networks and changes in egress routing. You can view the network latency between regions in the console.