一.DRDS实例性能评估分析目标
通常我们在分布式数据库选项过程中会对DRDS实例进行性能评估分析，我认为主要包含以下3个目的：
1.评估DRDS性能，判断DRDS是否满足预期的性能需求
2.获取DRDS性能容量及各负载条件下性能表现，为容量规划提供参考依据
3.定位诊断DRDS性能瓶颈及原因并调整优化
二.性能评估分析主要性能指标
1.资源指标：
CPU 利用率：DRDS 服务节点的CPU资源平均利用率
网络输入流量：DRDS 服务节点的网络输入流量的总和
网络输出流量：DRDS 服务节点的网络输出流量的总和
连接数：应用到 DRDS 的连接总数
活跃线程数：DRDS 用来执行 SQL 的线程数
产品业务性能指标：
逻辑 QPS：DRDS 服务节点每秒处理的 SQL 语句数目的总和
物理 QPS：DRDS 服务节点每秒发送到 RDS 的 SQL 操作数总和
逻辑 RT：DRDS 对于每条 SQL 的平均响应时间
物理 RT：DRDS 发送到 RDS 的 SQL 的平均响应时间
压测工具性能指标：
每秒SQL数：每秒压测工具执行的SQL数量总和
平均响应时间：压测工具的每个请求从发生到接受响应的平均延迟时间
三.性能评估分析原理及方法
上面这图是比较典型的负载、资源、吞吐量、响应时间之间的趋势关系
图例说明：
1.轻负载区：随着负载的增加，响应时间变化不大，系统资源利用率和TPS几乎线性增长
2.重负载区：随着负载持续的增加，资源开始趋于饱和，TPS到达拐点
3.崩溃区：随着负载的进一步增加，这时候的系统资源主要消耗在资源竞争和调度上，TPS反而开始保持平稳状态或开始下降，请求队列里的请求开始膨胀，响应时间开始快速上升
结合这个原理，一些经过实践总结的简单公式也可以帮助我们分析，前提条件，模拟的虚拟并发用户数没有思考时间，上一个请求完成后马上请求下一个：
从压测工具端来看：
TPS或QPS=并发用户数 / 响应时间
并发用户数 = TPS * 响应时间
响应时间 = 并发用户数 * TPS
DRDS端来看：
QPS=活跃线程数 / SQL逻辑时间
活跃线程数= QPS * SQL逻辑时间
SQL逻辑时间=活跃线程数 * QPS
四.性能评估压测工具使用
请查看地址：https://yq.aliyun.com/articles/133785
五.性能评估分析案例
1.压测环境
DRDS规格： 4C4G
压测表结构：一张用户表，按u_id进行分库
2.压测模型：
| SQL类型 |
SQL语句 |
SQL比例 |
| 插入 |
INSERT INTO `marcotest`.`user_tbl` (`u_name`, `u_phone`, `u_national` ) VALUES (?,?,'China'); |
20% |
| 查询 |
select * from `marcotest`.`user_tbl` where u_id=? |
70% |
| 更新 |
update `marcotest`.`user_tbl` set u_phone=? where u_id=? |
10% |
3.压测结果
通过Jmeter按压测模型来对DRDS发起压力，压测结果如下：
8并发：
16并发：
32并发：
48并发：
64并发：
80并发：
DRDS CPU资源利用率：
整理后的结果数据：
| 并发用户数 |
平均响应时间（ms） |
每秒SQL数（个） |
CPU平均利用率（百分比） |
| 8 |
4 |
1778 |
40% |
| 16 |
4 |
3490 |
70% |
| 32 |
5.5 |
5413 |
85% |
| 48 |
7.5 |
6095 |
90% |
| 64 |
9.5 |
6387 |
95% |
| 80 |
12 |
6483 |
99% |
4.性能分析：
在当前测试环境下，按压测模型进行压测，从结果数据结合分析方法原理来看，当并发超过32后以后QPS增长缓慢，并且CPU利用率趋于饱和，可以判断这个时候资源基本快达到瓶颈，导致吞吐量上涨受限。另外我们可以看到资源没有瓶颈的时候，响应时间基本保持平缓趋势，一旦资源饱和时，上涨趋势比较明显。
