This topic describes the specifications of data migration instances and provides the results of performance testing.

Precautions

The performance metrics provided in this topic are used only for reference and are not used as criteria for product SLA evaluation.

Terms

Term Description
specification DTS provides data migration instances that have different specifications. The performance of these instances depends on the performance of incremental data migration.
table quantity The total number of tables in the test model.
record size The size of each record that is migrated during incremental data migration.
RPS The number of records per second (RPS) that are changed by INSERT, UPDATE, and DELETE operations in the source database.
Note
  • If an SQL statement contains operations on multiple rows of data, DTS identifies the operations as multiple data changes. If you perform INSERT, UPDATE, and DELETE operations on a data record multiple times, DTS also identifies the operations as multiple data changes.
  • DTS identifies each COMMIT operation as a data change.

Specifications

DTS provide the following four specifications based on the maximum performance of data migration instances: small, medium, large, and 2xlarge. The data migration instance of each specification can reach the maximum performance if the following conditions are met:
  • The pressure on the source instance must be greater than or equal to the maximum performance that corresponds to each specification.
  • The destination instance does not have bottlenecks in write performance and supports the performance pressure that corresponds to each specification.
  • The network latency between the DTS server and the source or destination instance does not exceed 2 milliseconds.
Specification Maximum performance (RPS)
small 200 to 2,000
medium 2,000 to 5,000
large Unlimited
Note The online running performance of the large specification depends on the network environment and the performance of the source and destination instances.
2xlarge

Test model

Test procedure: Create an incremental migration task between two ApsaraDB RDS for MySQL instances. Then, perform a stress test on the source ApsaraDB RDS for MySQL instance to view the performance of incremental data migration.

Table 1. Test environment
Instance RDS instance configuration Maximum performance
Source instance
  • Instance specification: rds.mys2.8xlarge
  • Memory: 48,000 MB
  • Maximum connections: 2,000
  • Maximum QPS: 18,000
  • Maximum IOPS: 14,000
Destination instance
  • Instance specification: rds.mys2.8xlarge
  • Memory: 48,000 MB
  • Maximum connections: 2,000
  • Maximum QPS: 18,000
  • Maximum IOPS: 14,000

Test model:

  • The number of test tables is 20.
  • Each test table has a primary key.
  • The record size is 1 KB.
  • Each transaction has an average of two DML operations and one COMMIT operation. The ratio of INSERT, UPDATE, and DELETE operations is 3:1:2.

Test results

Source instance region Destination instance region Network latency between instances (milliseconds) Specification RPS
China (Hangzhou) China (Hangzhou) 0.26 small 2,566
China (Hangzhou) China (Hangzhou) 0.26 medium 4,726
China (Hangzhou) China (Hangzhou) 0.26 large 6,378
China (Hangzhou) China (Qingdao) 26 small 2,469
China (Hangzhou) China (Qingdao) 26 medium 4,856
China (Hangzhou) China (Qingdao) 26 large 5,439
China (Hangzhou) China (Beijing) 26 small 2,533
China (Hangzhou) China (Beijing) 26 medium 5,038
China (Hangzhou) China (Beijing) 26 large 6,829
China (Hangzhou) US (Silicon Valley) 175 small 1,753
China (Hangzhou) US (Silicon Valley) 175 medium 2,837
China (Hangzhou) US (Silicon Valley) 175 large 3,884
Singapore (Singapore) US (Silicon Valley) 198 small 1,104
Singapore (Singapore) US (Silicon Valley) 198 medium 1,724
Singapore (Singapore) US (Silicon Valley) 198 large 2,256
Note The preceding test results show the maximum performance of data migration instances that are configured with different specifications. The performance of incremental data migration cannot be guaranteed in the following cases: The table to be migrated does not have a primary key, the network latency is high, an update hotspot exists, or the source and destination instances have performance bottlenecks.