TencentDB for MySQL
- Release Notes and Announcements
- Announcements
- Product Introduction
- Database Architecture
- Database Instance
- Kernel Features
- Kernel Version Release Notes
- Functionality Features
- Performance Features
- Parallel Query
- Security Features
- Stability Features
- Purchase Guide
- Getting Started
- Connecting to MySQL Instance
- Database Audit
- Audit Rule Template
- MySQL Cluster Edition
- Maintenance Management Instance
- Operation Guide
- Instance Management and Maintenance
- Instance Upgrade
- CPU Elastic Expansion
- Read-Only/Disaster Recovery Instances
- Database Proxy
- Database Proxy Kernel Features
- Database Proxy Management
- Automatic Read/Write Separation Feature
- Connection Pool Feature
- Other Features
- Account Management
- Database Management Center (DMC)
- Parameter Configuration
- Network and Security
- Backup and Rollback
- Restoring Database from Backup File
- Monitoring and Alarms
- Operation Logs
- Practical Tutorial
- Calling MySQL APIs in Python
- White Paper
- Performance White Paper
- Performance Test Report
- Troubleshooting
- Connections
- API Documentation
- Data Import APIs
- Rollback APIs
- Parameter APIs
- Making API Requests
- Instance APIs
- Database Proxy APIs
- Database Audit APIs
- Security APIs
- Account APIs
- Backup APIs
- Database APIs
- Monitoring APIs
- Log-related API
- FAQs
- Backup
- Connection and Login
- Instance Upgrade
- Performance and Memory
- Service Agreement
- Reference
DocumentationTencentDB for MySQLWhite PaperPerformance White PaperPerformance Test ReportTest ResultsMySQL 8.0 Test Results
MySQL 8.0 Test Results
Last updated: 2024-07-23 17:41:50
This document describes the performance test results of a general TencentDB for MySQL 8.0 instance.
Scenario 1: Full Cache
In the full cache scenario, as all data can be put into the cache, the disk doesn't need to be read and written to update the cache during queries.
CPU (Core) | Memory (MB) | Concurrency | Data Volume/Table | Total Tables | SysBench TPS | SysBench QPS | avg_lat |
1 | 1000 | 8 | 25000 | 150 | 570.35 | 11406.9 | 14.03 |
1 | 2000 | 8 | 25000 | 150 | 634.44 | 12688.9 | 12.61 |
2 | 4000 | 16 | 25000 | 150 | 932.46 | 18649.2 | 17.16 |
4 | 8000 | 32 | 25000 | 150 | 2025.13 | 40502.7 | 15.8 |
4 | 16000 | 32 | 25000 | 150 | 2013.2 | 40264 | 15.89 |
8 | 16000 | 64 | 25000 | 150 | 3555.2 | 71104.1 | 18 |
8 | 32000 | 64 | 25000 | 150 | 3564.24 | 71284.7 | 17.95 |
16 | 32000 | 128 | 25000 | 150 | 5767.44 | 115349 | 22.19 |
16 | 64000 | 128 | 25000 | 150 | 6558.19 | 131164 | 19.51 |
16 | 96000 | 128 | 25000 | 150 | 6517.01 | 130340 | 19.63 |
16 | 128000 | 128 | 25000 | 150 | 6539.98 | 130800 | 19.57 |
Scenario 2: Disk I/O
In the disk I/O scenario, as only part of the data can be put into the cache, the disk needs to be read and written to update the cache during queries.
CPU (Core) | Memory (MB) | Concurrency | Data Volume/Table | Total Tables | SysBench TPS | SysBench QPS | avg_lat |
1 | 1000 | 8 | 800000 | 6 | 582.76 | 11655.1 | 13.73 |
1 | 2000 | 8 | 800000 | 12 | 588.92 | 11778.4 | 13.58 |
2 | 4000 | 16 | 800000 | 24 | 899.06 | 17981.2 | 17.8 |
4 | 8000 | 32 | 800000 | 48 | 1915.83 | 38316.6 | 16.7 |
4 | 16000 | 32 | 6000000 | 13 | 1884.2 | 37684 | 16.98 |
8 | 16000 | 64 | 6000000 | 13 | 3356.71 | 67134.2 | 19.06 |
8 | 32000 | 64 | 6000000 | 25 | 3266.73 | 65334.6 | 19.59 |
16 | 32000 | 128 | 6000000 | 25 | 5370.18 | 107404 | 23.83 |
16 | 64000 | 128 | 6000000 | 49 | 5910.85 | 118217 | 21.65 |
16 | 96000 | 128 | 6000000 | 74 | 5813.94 | 116279 | 22.01 |
16 | 128000 | 128 | 6000000 | 98 | 5700.06 | 114001 | 22.45 |
Was this page helpful?
You can also Contact Sales or Submit a Ticket for help.
Yes
No