Global Replica for Redis features high performance and low latency. This topic describes how to test the synchronization latency between child instances in different regions.

Overview

Global Distributed Cache for Redis is an active geo-redundancy database system that is developed based on ApsaraDB for Redis. Global Distributed Cache for Redis supports business scenarios in which multiple sites in different regions provide services at the same time. It helps enterprises replicate the active geo-redundancy architecture of Alibaba. For more information, see Overview.

Test environment

In this example, the distributed instance contains three child instances that reside in the China (Beijing), China (Shanghai), and China (Shenzhen) regions. Each child instance is deployed in a different region.

Figure 1. Regions of child instances
Regions of child instances
Environment item Description
Child instance architecture The child instances are deployed in the cluster architecture.
Child instance type The test results vary little as the instance type changes. In this example, the instances of the redis.amber.logic.sharding.2g.8db.0rodb.24proxy.multithread type are used. For more information, see Performance-enhanced cluster instances.
Server on which the test tool is deployed The test tool is deployed on three Elastic Compute Service (ECS) instances that reside in the China (Beijing), China (Shanghai), and China (Shenzhen) regions. Each instance is deployed in a different region.

Test tool

The test tool is replicator-delay-test, which calculates the difference between the point in time when a key is read on the destination instance and the value of the key to obtain the latency.

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

Test method

In the following example, the latency is tested for data synchronization from the child instance in the China (Beijing) region to the child instance in the China (Shenzhen) region. The synchronization latency between child instances in other regions can be tested in the same way.

Figure 2. Environment for testing synchronization latency
Environment for testing synchronization latency
  1. Log on to the ECS instance in the China (Shenzhen) region and run a command in the following format:
    java -jar replicator-delay-test.jar ${host} ${port} ${password} ${keynumber} get
    Note The test tool reads keys from the child instance in the China (Shenzhen) region. The keys were synchronized from the child instance in the China (Beijing) region. The test tool calculates the difference between the point in time when a key is read and the value of the key to obtain the latency.
    Parameter Description
    {host} The private endpoint of the child instance in the China (Shenzhen) region. For more information about how to obtain the private endpoint, see View endpoints.
    {port} The port number that is used to connect to the child instance in the China (Shenzhen) region. Default value: 6379.
    {password} The password that is used to connect to the child instance in the China (Shenzhen) region.
    Note If you use an account that is created on the child instance after the child instance is created, specify the password in the <user>:<password> format. For example, if the username of the account is admin and the password is Rp829dlwa, use admin:Rp829dlwa as the password to connect to the child instance.
    {keynumber} The number of keys that you want to read.
  2. Log on to the ECS instance in the China (Beijing) region and run a command in the following format:
    java -jar replicator-delay-test.jar ${host} ${port} ${password} ${keynumber} set
    Note The test tool continuously creates keys on the child instance in the China (Beijing) region. The test tool uses incremental integers as the names of the keys, and uses the timestamps when the keys are created as the values of the keys.
    Parameter Description
    {host} The private endpoint of the child instance in the China (Beijing) region. For more information about how to obtain the private endpoint, see View endpoints.
    {port} The port number that is used to connect to the child instance in the China (Beijing) region. Default value: 6379.
    {password} The password that is used to connect to the child instance in the China (Beijing) region.
    Note If you use an account that is created on the child instance after the child instance is created, specify the password in the <user>:<password> format. For example, if the username of the account is admin and the password is Rp829dlwa, use admin:Rp829dlwa as the password to connect to the child instance.
    {keynumber} The number of keys that you want to write. It must be the same as the number of keys to read that you specify in Step 1.
  3. Wait until the test tool on the ECS instance in the China (Shenzhen) region reads the specified number of keys. Then, the test tool displays the latency information about data synchronization from the child instance in the China (Beijing) region to the child instance in the China (Shenzhen) region.

Test result

The following metrics are provided in the Test result table:

Average latency
The average latency for synchronizing all keys in this test. Unit: milliseconds.
95th
The highest latency that is obtained when 95% of the keys are synchronized. Unit: milliseconds. For example, if the value of this metric is 20 milliseconds, 95% of the keys are synchronized within 20 milliseconds.
99th
The highest latency that is obtained when 99% of the keys are synchronized. Unit: milliseconds. For example, if the value of this metric is 50 milliseconds, 99% of the keys are synchronized within 50 milliseconds.
Table 1. Test result
Region of the source child instance Region of the destination child instance Average latency (milliseconds) 95th (milliseconds) 99th (milliseconds)
China (Beijing) China (Shanghai) 28.35 39.0 54.5
China (Shenzhen) 34.2 69.5 103.0
China (Shanghai) China (Beijing) 28.35 39.0 54.5
China (Shenzhen) 29.0 40.6 61.7
China (Shenzhen) China (Shanghai) 29.0 40.6 61.7
China (Beijing) 34.2 69.5 103.0
Note If the network link is long, such as in scenarios of synchronization between regions across continents, the round-trip time (RTT) of the network link is the main factor that affects the synchronization latency. The synchronization latency changes with the conditions of carrier networks and egress routes. In most cases, the synchronization latency is about 100 milliseconds to several seconds.