DRDS和RDS只读实例性能对比测试

本文涉及的产品
云原生数据库 PolarDB 分布式版,标准版 2核8GB
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
云数据库 RDS MySQL,集群系列 2核4GB
推荐场景:
搭建个人博客
简介: 我们都知道,对于数据库中基础信息表来说,它的数据变化频率低,数据量小,但由于基础数据本身的特点,大多数相关系统都会对频繁地读取它。即便我们通过对数据调取服务进行服务化包装,通过HSF服务的方式对外暴露,以减少多个系统直接操作数据库带来的问题,但数据本身的读取频率和并发度都非常高,QPS可以轻易达到10万以上。

作者:回雁

我们都知道,对于数据库中基础信息表来说,它的数据变化频率低,数据量小,但由于基础数据本身的特点,大多数相关系统都会对频繁地读取它。即便我们通过对数据调取服务进行服务化包装,通过HSF服务的方式对外暴露,以减少多个系统直接操作数据库带来的问题,但数据本身的读取频率和并发度都非常高,QPS可以轻易达到10万以上。通常,使用普通的关系型数据库,比如RDS很难满足这样的场景,业内普遍的做法是在数据库前加一层数据库缓存服务,比如redis或memcache来存放基础信息,以此承载海量的高并发访问请求。但是也会存在问题,当缓存服务发生故障,或者由于某种异常被击穿,大量的访问请求迅速会打到后端的数据库上,数据库能不能在关键时候扛住压力,为运维人员争取时间,快速修复缓存服务,显得至关重要。

是的,这个时候,阿里云RDS和DRDS都提供了只读实例,从原理上来说,RDS只读实例使用的 MySQL主备复制,一个主库最多支持5个备库,备库提供只读访问,用户程序访问备库时使用与主库不同的地址。而DRDS只读实例(读写分离)其实底层依赖的就是RDS的只读实例,但是DRDS作为数据库中间件,为1个主实例和多个只读实例提供了统一的访问入口,当DRDS设置了读写分离时,对用户程序是透明的,用户只需要在DRDS控制台上自由调整只读实例的读比例即可。在比较新的版本中,RDS也支持了读写分离,但是在专有云v2版本中暂时还没有支持。

那么,RDS的只读实例和DRDS的读写分离在性能上是否存在差异,我们在阿里云专有云的环境做一个测试,来验证这个问题。

一.准备环境

1.1 资源清单

资源类型 规格 数量
RDS主实例 48G内存,磁盘100GB 1
RDS只读实例 48G内存,磁盘100GB 5
DRDS实例 8节点,64Core CPU,128GB内存 1
测试压力机ECS 16Core CPU,64GB内存 3

1.2 创建测试表

在DRDS建立非分库分表的测试表:

IMG_20200403_152200.jpg

1.3 在DRDS中导入测试数据

mysql -u用户名 -p密码 -hDRDSIP -P3306 DRDS库名< bic_base_org_insert.sql

1.4 查看表大小

mysql> select count(*) from bic_base_org;

+----------+

| count(*) |

+----------+

|   191087 |

+----------+

1 row in set (0.03 sec)

1.5 执行计划

mysql> explain select id,inst_id,code,name_cn,aic_register_name,postcode,administrative_division,province_code,city_code,status,business_unit,org_level,org_category,manage_level,parent_org_code,erp_parent_org_code   from bic_base_org where id=170000;

+------------------------------------------------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+--------+

| GROUP_NAME                                                       | SQL                                                                                                                                                                                                                                        | PARAMS |

+------------------------------------------------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+--------+

| DRDS_XNCS_BIC_CS_1513840820139DMOXDRDS_XNCS_BIC_CS_CJWT_0000_RDS | select id,inst_id,code,name_cn,aic_register_name,postcode,administrative_division,province_code,city_code,status,business_unit,org_level,org_category,manage_level,parent_org_code,erp_parent_org_code   from bic_base_org where id=170000 | {}     |

+------------------------------------------------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+--------+

1 row in set (0.00 sec)

 

mysql> explain execute  select id,inst_id,code,name_cn,aic_register_name,postcode,administrative_division,province_code,city_code,status,business_unit,org_level,org_category,manage_level,parent_org_code,erp_parent_org_code   from bic_base_org where id=170000;

+----+-------------+--------------+-------+---------------+---------+---------+-------+------+-------+

| id | select_type | table        | type  | possible_keys | key     | key_len | ref   | rows | Extra |

+----+-------------+--------------+-------+---------------+---------+---------+-------+------+-------+

|  1 | SIMPLE      | bic_base_org | const | PRIMARY       | PRIMARY | 8       | const |    1 | NULL  |

+----+-------------+--------------+-------+---------------+---------+---------+-------+------+-------+

1 row in set (0.01 sec)

可以看到 ,SQL在DRDS0号分库上执行,并且执行计划是主键查询,这是最快的方式。

二.测试语句

2.1 测试语句:

vi select.sql

 

select id,inst_id,code,name_cn,aic_register_name,postcode,administrative_division,province_code,city_code,status,business_unit,org_level,org_category,manage_level,parent_org_code,erp_parent_org_code   from bic_base_org where id=170000;

这个语句非常简单,只是针对单表基于索引字段id查询一条记录的某些字段,我们重点考察的是大并发下只读实例的性能表现。

2.2 测试工具:

mysqlslap

三.测试过程

测试分为两大组:

第一组并发100,对比RDS,RDS只读实例,DRDS 1个只读实例和DRDS 5个只读实例的性能表现。3.1-3.4是第一组测试数据。

第二组将增加并发,进行摸高测试,观察资源的瓶颈和系统的极限。3.5-3.9是第二组测试数据。

3.1 RDS主实例测试(100并发)

测试说明:100并发,总共跑1千万条相同的主键查询:

mysqlslap  --query=/select.sql --concurrency=100 --number-of-queries=10000000  --iterations=1 --create-schema=drds_xncs_bic_cs_trou_0000 --engine=innodb  -hRDSIP地址 -u用户名 -p密码

 

Benchmark

         Running for engine innodb

         Average number of seconds to run all queries: 154.738 seconds

         Minimum number of seconds to run all queries: 154.738 seconds

         Maximum number of seconds to run all queries: 154.738 seconds

         Number of clients running queries: 100

         Average number of queries per client: 100000

QPS=10000000/154.738=64625,该场景下,资源没有瓶颈。

注:后面每个测试案例的命令与本案例相似,所以略去测试命令,只展示测试结果。

3.2 RDS只读实例测试(100并发)

测试说明:100并发,总共跑 1千万条相同的主键查询:

Benchmark

         Running for engine innodb

         Average number of seconds to run all queries: 150.370 seconds

         Minimum number of seconds to run all queries: 150.370 seconds

         Maximum number of seconds to run all queries: 150.370 seconds

         Number of clients running queries: 100

         Average number of queries per client: 100000

QPS=10000000/150.370=66502,该场景下,资源没有瓶颈。

3.3 DRDS测试(1个只读实例,100并发)
测试说明:(把其中一个slave库读比例设100% 测drds下一个备库 ) 100并发,共跑 1千万条相同的主键查询:

Benchmark

         Running for engine innodb

         Average number of seconds to run all queries: 235.556 seconds

         Minimum number of seconds to run all queries: 235.556 seconds

         Maximum number of seconds to run all queries: 235.556 seconds

         Number of clients running queries: 100

         Average number of queries per client: 100000

QPS=10000000/235.556=42453,该场景下,资源没有瓶颈。

3.4 DRDS测试(5个只读实例,100并发)
测试说明:5个只读每个开20%,100并发,总共跑1千万条相同的主键查询:

Benchmark

         Running for engine innodb

         Average number of seconds to run all queries: 216.412 seconds

         Minimum number of seconds to run all queries: 216.412 seconds

         Maximum number of seconds to run all queries: 216.412 seconds

         Number of clients running queries: 100

         Average number of queries per client: 100000

QPS=10000000/216.412=46208,该场景下,资源没有瓶颈。
第一组测试结束,低压力(100并发)下,RDS主实例和只读实例性能大致相同,DRDS 1个只读实例和5个只读实例的配置对比,性能也基本相似,且不如RDS的性能,这是符合预期的,因为在没有达到性能极限前,DRDS会比RDS多一层开销。第二组测试中,数据考虑到单台ECS性能并发量的局限性,于是采用多台ECS并发测试,通过DRDS和RDS控制台观察数据,重点关注整体吞吐能力和极限。

3.5 RDS主实例测试(1500并发)
测试说明:共1500并发,两个ECS执行分别1000,500并发,总共跑 20亿条相同的主键查询:

image.png

image.png

RDS连接数:75%(1500),RDS最大连接数为2000

RDSQPS:接近70000

RDS CPU:接近100%,出现瓶颈

SQL的执行时间:几百-几万微秒

3.6 RDS主实例测试(1900并发)

测试说明:共1900并发,三个ECS执行分别1000,500,400 并发,总共跑 30亿条相同的主键查询。
image.png

image.png

RDS连接数:1900,达到瓶颈

RDS QPS:接近70000

RDS CPU:接近100%,达到瓶颈

SQL的执行时间:几百-几万微秒

3.7 DRDS(5个只读实例,1000并发)

测试说明:5个只读每个开20%,1000并发,总共跑1亿条相同的主键查询:

Benchmark

         Running for engine innodb

         Average number of seconds to run all queries: 1790.584 seconds

         Minimum number of seconds to run all queries: 1790.584 seconds

         Maximum number of seconds to run all queries: 1790.584 seconds

         Number of clients running queries: 1000

         Average number of queries per client: 100000

QPS=100000000/1790=55866,该场景下,资源没有瓶颈。

3.8 DRDS(5个只读实例,10000并发)

测试说明:(5个只读每个开20%) 共10000并发,两个ECS执行分别5000 总共跑 20亿条相同的主键查询:
image.png

image.png

image.png

物理RT:1.1ms左右

QPS:大约125000左右

RDS SQL执行时间:100微秒左右

客户端ECS千兆网卡打满,出现瓶颈

3.9 DRDS(5个只读实例,15000并发)

测试说明:(5个只读每个开20%) 共15000并发,三个ECS执行分别5000 总共跑 30亿条相同的主键查询。

image.png

image.png

DRDS QPS:大约210000左右

RDS上SQL的执行时间:100微秒左右

物理RT:2.1ms左右

客户端ECS网卡被打满,出现瓶颈

四.测试总结:

数据库 连接数 QPS RT/SQL执行时间 瓶颈分析
RDS主实例 100 64625 15.4us 没有瓶颈
RDS只读实例 100 66502 15.0us 没有瓶颈
DRDS(1主+1只读) 100 42453 23.6us 没有瓶颈
DRDS(1主+5只读) 100 46208 21.6us 没有瓶颈
RDS主实例 1500 69980 几百~几万us RDS CPU打满
RDS主实例 1900 69000 几百~几万us RDS CPU、连接数打满
DRDS(1主+5只读) 1000 55866 17.9us 没有瓶颈
DRDS(1主+5只读) 10000 125000 1.9ms(DRDS)100us(RDS) 加压ECS网卡打满
DRDS(1主+5只读) 15000 210000 11.2ms(DRDS)100us(DRDS) 加压ECS网卡打满

4.1 单台ECS客户端低压力测试

RDS主实例和只读实例性能基本相同;
只有1个只读实例的DRDS耗时比单RDS主实例或单RDS只读实例相差较大,大约损失35%的性能;
开满5个只读实例的DRDS耗时比单RDS主实例或者单RDS只读实例相差较大,大约损失29%的性能;
低压力下测试场景,平均RT在几十微秒这个数量级。

4.2 多台ECS客户端大压力极限测试

RDS单个主实例配置2000最大并发数,选用1900并发,QPS达到69000,响应时间在毫秒级。此时连接数和CPU都已经接近极限;
DRDS开满5个只读实例,三台ECS到达15000的并发,DRDS的QPS可以达到210000左右,响应时间达到毫秒级。此时除客户端ECS达到极限外,RDS和DRDS均有资源剩余可用;
因为DRDS是数据库中间件,同时有内置连接池,所以从单个连接的SQL性能来说,DRDS不如RDS,但差异只体现在微秒这个数量级;而正因为DRDS有内置连接池,大规模大量连接高并发场景下,DRDS体现出优势,且响应时间还保持在毫秒级别,可以接受;
RDS读写分离由于专有云还不支持,所以没有进行测试,预期会比单实例RDS性能稍差。从数据库连接数来看,也不如DRDS支持得多,需要在应用程序中设置连接池,从而满足更高的并发需求。

相关实践学习
快速体验PolarDB开源数据库
本实验环境已内置PostgreSQL数据库以及PolarDB开源数据库:PolarDB PostgreSQL版和PolarDB分布式版,支持一键拉起使用,方便各位开发者学习使用。
相关文章
|
1月前
|
机器学习/深度学习 人工智能 监控
提升软件质量的关键路径:高效测试策略与实践在软件开发的宇宙中,每一行代码都如同星辰般璀璨,而将这些星辰编织成星系的过程,则依赖于严谨而高效的测试策略。本文将引领读者探索软件测试的奥秘,揭示如何通过精心设计的测试方案,不仅提升软件的性能与稳定性,还能加速产品上市的步伐,最终实现质量与效率的双重飞跃。
在软件工程的浩瀚星海中,测试不仅是发现缺陷的放大镜,更是保障软件质量的坚固防线。本文旨在探讨一种高效且创新的软件测试策略框架,它融合了传统方法的精髓与现代技术的突破,旨在为软件开发团队提供一套系统化、可执行性强的测试指引。我们将从测试规划的起点出发,沿着测试设计、执行、反馈再到持续优化的轨迹,逐步展开论述。每一步都强调实用性与前瞻性相结合,确保测试活动能够紧跟软件开发的步伐,及时适应变化,有效应对各种挑战。
|
2月前
|
测试技术 数据库 UED
Python 性能测试进阶之路:JMeter 与 Locust 的强强联合,解锁性能极限
【9月更文挑战第9天】在数字化时代,确保软件系统在高并发场景下的稳定性至关重要。Python 为此提供了丰富的性能测试工具,如 JMeter 和 Locust。JMeter 可模拟复杂请求场景,而 Locust 则能更灵活地模拟真实用户行为。结合两者优势,可全面评估系统性能并优化瓶颈。例如,在电商网站促销期间,通过 JMeter 模拟大量登录请求并用 Locust 模拟用户浏览和购物行为,可有效识别并解决性能问题,从而提升系统稳定性和用户体验。这种组合为性能测试开辟了新道路,助力应对复杂挑战。
108 2
|
1月前
|
监控 测试技术 PHP
性能和压力测试
【10月更文挑战第10天】性能和压力测试
111 60
|
2月前
|
缓存 Java 测试技术
谷粒商城笔记+踩坑(11)——性能压测和调优,JMeter压力测试+jvisualvm监控性能+资源动静分离+修改堆内存
使用JMeter对项目各个接口进行压力测试,并对前端进行动静分离优化,优化三级分类查询接口的性能
谷粒商城笔记+踩坑(11)——性能压测和调优,JMeter压力测试+jvisualvm监控性能+资源动静分离+修改堆内存
|
1月前
|
测试技术 PHP 开发工具
php性能监测模块XHProf安装与测试
【10月更文挑战第13天】php性能监测模块XHProf安装与测试
29 0
|
2月前
|
敏捷开发 安全 测试技术
软件测试的艺术:确保质量与性能的平衡之道
【9月更文挑战第24天】在软件开发的海洋中,测试是导航灯塔,指引着项目安全抵达质量的彼岸。本文将深入探讨软件测试的核心原则、方法论以及如何通过精心设计的测试策略来保障产品的可靠性和性能。我们将从测试的基础知识出发,逐步深入到高级测试技巧,最终展示如何通过实际案例来应用这些知识以确保软件的成功交付。
|
2月前
|
测试技术 Python
软件测试的艺术:确保质量与性能
【9月更文挑战第19天】在数字化时代,软件已成为我们生活的一部分。然而,随着软件复杂性的增加,如何确保其质量和性能成为了一个挑战。本文将探讨软件测试的重要性,介绍常见的测试类型和策略,并提供实用的代码示例来帮助读者更好地理解和应用这些测试方法。无论你是开发人员、测试工程师还是项目管理者,这篇文章都将为你提供有价值的见解和技巧。
|
2月前
|
存储 Java 关系型数据库
“代码界的魔法师:揭秘Micronaut框架下如何用测试驱动开发将简单图书管理系统变成性能怪兽!
【9月更文挑战第6天】Micronaut框架凭借其轻量级和高性能特性,在Java应用开发中备受青睐。本文通过一个图书管理系统的案例,介绍了在Micronaut下从单元测试到集成测试的全流程。首先,我们使用`@MicronautTest`注解编写了一个简单的`BookService`单元测试,验证添加图书功能;接着,通过集成测试验证了`BookService`与数据库的交互。整个过程展示了Micronaut强大的依赖注入和测试支持,使测试编写变得更加高效和简单。
76 4
|
3月前
|
消息中间件 Kafka 测试技术
【Azure 事件中心】使用Kafka的性能测试工具(kafka-producer-perf-test)测试生产者发送消息到Azure Event Hub的性能
【Azure 事件中心】使用Kafka的性能测试工具(kafka-producer-perf-test)测试生产者发送消息到Azure Event Hub的性能
|
3月前
|
缓存 NoSQL 测试技术
【Azure Redis 缓存 Azure Cache For Redis】使用Redis自带redis-benchmark.exe命令测试Azure Redis的性能
【Azure Redis 缓存 Azure Cache For Redis】使用Redis自带redis-benchmark.exe命令测试Azure Redis的性能