This topic describes guidelines on how to compare the performance of Apsara PolarDB and Relational Database Service (RDS).
Before you begin, make sure that the following conditions are met for obtaining accurate results of the performance comparison.
- Apsara PolarDB and RDS clusters use the same specifications.
- Apsara PolarDB and RDS clusters are created in the same version.
Every version of a product provides different implementation mechanisms. For example, MySQL 8.0 is optimized for multi-core CPUs and provides threads such as log_writer, log_fluser, log_checkpoint, and log_write_notifier. However, the performance of MySQL 8.0 is lower than MySQL 5.6/5.7 when the cluster is allocated only a small number of CPU cores. We recommend that you do not compare the performance of ApsaraDB PolarDB MySQL-compatible edition 5.6 and ApsaraDB RDS for MySQL 5.7/8.0, because MySQL 5.7/8.0 uses a new optimizer, which is better than that of MySQL 5.6.
- Perform the performance comparison in a staging environment or use sysbench. This allows you to obtain expected results that meet the requirements of your workloads.
- Do not use a single SQL statement to test the read performance.
Apsara PolarDB runs in a computing and storage separated architecture. The read performance tested based on a single statement can be affected by the network latency. Consequently, the test result may indicate that the performance of RDS is higher than Apsara PolarDB. 99% queries can hit in the cache of online databases. Only the first read request calls the I/O interface, which degrades the read performance. For subsequent requests, data is directly read from the buffer pool. This means that the read performance is not affected when the database processes these requests.
- Do not use a single SQL statement to test the write performance. To obtain an expected result, perform the performance comparison in a staging environment.
Make sure that the Apsara PolarDB cluster contains primary and read-only nodes, and the RDS cluster contains master and semi-synchronous read-only instances. By default, Apsara PolarDB uses the Quorum mechanism for writes. If Apsara PolarDB successfully writes data to two or more of the three replicas, the write operation is considered successful. Apsara PolarDB implements data redundancy in the storage plane and ensures high consistency and high availability of the three replicas. We recommend that you use semi-synchronous replication instead of asynchronous replication of ApsaraDB RDS for MySQL to obtain an expected test result.
For more information about performance comparison results, see Comparison with ApsaraDB RDS for MySQL.