This topic provides reference performance data for replication workloads in data migration mode. It describes actual performance tests and lists the results of the tests.
Precautions
The performance data provided in this document should only be used for reference when you plan the capacity of your replication workloads. The data in this document are not guaranteed performance levels and the actual performance of your migration tasks may differ from the data provided. For performance levels guaranteed by DTS, see the Service Level Agreement (SLA).
Terms
Term | Description |
Instance size | DTS provides multiple instance sizes that have different performance. The performance of incremental data migration is measured as an indicator of instance performance. |
Table count | The total number of tables used in the test method. |
Record size | The size of record that is migrated during incremental data migration. |
RPS | The number of records per second (RPS) that are updated by INSERT, UPDATE, and DELETE operations in the source database during incremental data migration. |
If an SQL statement operates on multiple rows, DTS identifies the operation as multiple data updates. If you perform INSERT, UPDATE, and DELETE operations on a data record multiple times, DTS also identifies the operations as multiple data updates.
DTS identifies each COMMIT operation as a data update.
Instance size
DTS supports the following five instance sizes that provide data migration tasks with different maximum performance: small, medium, large, xlarge, and 2xlarge. The data migration tasks can reach the maximum performance when the following conditions are met:
The workload on the source instance must be no less than the maximum performance supported by the instance size.
The target instance does not have poor write performance and supports the maximum performance supported by the instance size.
The network latency between the DTS server and the source or target instance is no more than 2 milliseconds.
Instance size | Maximum performance (RPS) |
small | 2,000 |
medium | 5,000 |
large | 6,000 |
xlarge | 7,000 |
2xlarge | 11,000 |
The performance data provided in the preceding table should only be used for reference because the actual performance is affected by factors including network stability and the performance of the source and target databases.
Test method
In this test, we created an incremental migration task between two ApsaraDB RDS for MySQL instances. Then, we performed a stress test that made highly frequent updates to the source ApsaraDB RDS for MySQL instance and viewed the performance metrics of the data migration task.
Instance | RDS instance configuration | Maximum performance |
Source instance |
|
|
Target instance |
|
|
The number of test tables is 20.
Each test table has a primary key.
The size of each record 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 | Target instance region | Network latency between instances (milliseconds) | Instance size | 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 | US (Silicon Valley) | 198 | small | 1,104 |
Singapore | US (Silicon Valley) | 198 | medium | 1,724 |
Singapore | US (Silicon Valley) | 198 | large | 2,256 |
These test results indicate the maximum performance of data migration tasks that are configured with different instance sizes. Many other factors may affect the performance of incremental data migration. For example, the performance is reduced if the table to be migrated does not have a primary key, if the network latency is high, or if the source and target database servers operate at low performance.