Before benchmarking a user-created database against an ApsaraDB for RDS instance, align five conditions: network environment, specifications, database engine version, data replication mode, and parameter settings. A mismatch in any one of them skews results and produces invalid conclusions.
We recommend purchasing an ApsaraDB for RDS instance. ApsaraDB for RDS is fully hosted and includes a complete suite of solutions covering security, backup, restoration, scaling, and performance optimization. This eliminates the need to create secondary databases, allowing you to focus on business development and innovation.
For a detailed comparison of the two hosting models, see Competitive advantages of ApsaraDB for RDS instances over user-created databases.
Network environment
Deploy the application and the user-created database on separate ECS instances, all in the same region as the ApsaraDB for RDS instance. This lets both databases communicate with the application over the internal network under identical network conditions.
If the application and the user-created database share the same ECS instance, the network path from the application to the user-created database is shorter than the path to the ApsaraDB for RDS instance. The application also competes for CPU resources on that instance. Both factors artificially favor the user-created database and invalidate the comparison.
Deploy using one of the following topologies:
-
The application, user-created database, and ApsaraDB for RDS instance all reside in the same zone.
-
The user-created database and the ApsaraDB for RDS instance reside in the same zone; the application resides in a different zone within the same region.
Specifications
The ECS instance hosting the user-created database must have the same number of CPU cores and memory capacity as the ApsaraDB for RDS instance. A mismatch in either dimension directly distorts throughput and latency results.
Database engine version
Run the same database engine version on both sides. For example, if the ApsaraDB for RDS instance runs MySQL 5.6, the user-created database must also run MySQL 5.6. Version differences can introduce query planner behavior changes unrelated to the hosting model.
Data replication mode
Data replication adds write latency, so the replication configuration must match on both sides. ApsaraDB for RDS supports asynchronous, semi-synchronous, and synchronous replication. For instructions on changing the mode, see Modify the data replication mode.
Match configurations based on your setup:
| User-created database | ApsaraDB for RDS instance |
|---|---|
| No secondary databases; no data replication | High-availability Edition; asynchronous replication |
| One secondary database; asynchronous replication | High-availability Edition; asynchronous replication |
| One secondary database; semi-synchronous replication | High-availability Edition; semi-synchronous replication |
Parameter settings
Parameter mismatches frequently cause invalid benchmarks. Use the same parameter settings on both sides. To reconfigure parameters on the ApsaraDB for RDS instance, see Use the console to set parameters.
ApsaraDB for RDS restricts modification of certain parameters for security reasons. If a parameter cannot be changed on the RDS side, adjust it on the user-created database instead.
Example: SQL execution time 2x slower on RDS after migration
A customer migrating from an on-premises data center found that SQL statements ran twice as long on ApsaraDB for RDS as on their user-created database. The root cause was a parameter mismatch:
| Parameter | User-created database | ApsaraDB for RDS instance |
|---|---|---|
join_buffer_size |
128M | 1M |
read_rnd_buffer_size |
128M | — |
read_buffer_size |
— | 1M |
tmp_table_size |
128M | 256K |