All Products
Search
Document Center

ApsaraDB RDS:Performance test on an ApsaraDB RDS instance that runs MySQL 5.6 and uses Premium Local SSDs

Last Updated:Mar 30, 2026

This page provides Sysbench benchmark results for ApsaraDB RDS for MySQL 5.6 instances using the general-purpose instance family and local disks. Use these numbers as a reference when sizing an instance for your workload.

All results are based on a 20-minute stress test to simulate production-level load. Results are for reference only. For help resolving slow queries on a running instance, see Troubleshoot slow SQL statements on an ApsaraDB RDS for MySQL instance.

Test environment

Sysbench stress-tested five instance types, all running RDS High-availability Edition with local disk storage.

Attribute Value
Instance family General-purpose
RDS edition High-availability Edition
Storage type Local disk
Instance types tested rds.mysql.s1.small, rds.mysql.s2.large, rds.mysql.m1.medium, rds.mysql.c1.xlarge, rds.mysql.c2.xlarge

Test parameters

Performance results are sensitive to data volume, test duration, and parameter settings. The following configuration was used across all tests.

Test duration: 20 minutes per instance.

MySQL parameter settings:

Parameter Value Effect
sync_binlog 1 Flushes the binary log to disk on every commit
innodb_flush_log_at_trx_commit 1 Writes and flushes the InnoDB log on every transaction commit
rpl_semi_sync_master_enabled ON Enables semi-synchronous replication to ensure data consistency between primary and secondary instances
Performance_schema OFF Auto-enabled for instances with 64 GB memory or more

These parameters match the standard parameter template for ApsaraDB RDS for MySQL, which maximizes data consistency and keeps the test environment close to production conditions.

Test results

Two test scenarios cover the most common production workload patterns. Choose the scenario that matches your data volume.

Cache-based queries

In this scenario, the entire dataset fits in the InnoDB buffer pool, so queries are served from memory without disk reads. This scenario applies to small datasets.

To change the InnoDB buffer pool size, see Change the size of the InnoDB buffer pool for an ApsaraDB RDS for MySQL instance.

image.png
Instance type Data volume per table Tables Max connections IOPS Sysbench threads QPS TPS
1 core, 2 GB (rds.mysql.s1.small) 3,000,000 1 600 1,000 16 12,761 638
2 cores, 4 GB (rds.mysql.s2.large) 3,000,000 2 1,200 2,000 16 27,521 1,306
4 cores, 16 GB (rds.mysql.m1.medium) 6,000,000 4 4,000 7,000 32 59,185 2,959
8 cores, 32 GB (rds.mysql.c1.xlarge) 6,000,000 8 8,000 12,000 32 91,941 4,597
16 cores, 64 GB (rds.mysql.c2.xlarge) 6,000,000 16 16,000 14,000 64 129,953 6,498

Disk I/O-based queries

In this scenario, only the most frequently accessed data fits in the InnoDB buffer pool. Queries require disk reads and writes, and the buffer pool is continuously updated. This scenario applies to large datasets.

image.png
Instance type Data volume per table Tables Max connections IOPS Sysbench threads QPS TPS
1 core, 2 GB (rds.mysql.s1.small) 16,000,000 1 600 1,000 16 1,087 54
2 cores, 4 GB (rds.mysql.s2.large) 16,000,000 2 1,200 2,000 16 2,382 119
4 cores, 16 GB (rds.mysql.m1.medium) 32,000,000 4 4,000 7,000 32 8,814 441
8 cores, 32 GB (rds.mysql.c1.xlarge) 32,000,000 8 8,000 12,000 32 15,195 760
16 cores, 64 GB (rds.mysql.c2.xlarge) 32,000,000 16 16,000 14,000 32 17,764 888