性能测试工具 做好第一次 jmeter 压测数据库
第一次分享，请大家多多支持！
测试背景：项目组开发使用数据库 mycat 分片，需要对 mycat 数据库进行压测
领导转给我一个网络上的文档（jmeter 压测 jdbc），让我照搬着做
下面是一些工作总结：
Jmeter 链接 jdbc 用到的配置元件：JDBC Connection Configuration
主要作用：存储数据库信息链接数据库
JDBC 专用的请求：JDBC Request
主要作用：编写 sql 语句放在这里
“都需要测试哪些场景呢？”
开发回答：“增删改查”
首先了解了分片规则和设计表结构：
Mycat-part 数据库做为压测库，和原始库 db-00-db20 二十一个库中有相同的三张表
在 Mycat-part 库中执行 sql 语句，结果会通过租户 ID 字段复制到原始库的 db00-db20 的相同表中（纯属个人理解）
接下来就开始编写一些简单的 sql 语句
写入：id 使用计数器参数化，租户 id 使用计数器参数化 范围 0-20（通过 insert 语句准备测试数据，每张表 4W 数据）
更新：“名称 A” 修改为 “名称 B”
“名称 A” 修改为 “名称 B” AND 租户 ID
查询：“通过名称 A” 查询 “组织名称”（关联表查询）
删除：通过 id 删除
采用梯度加压的方式在 linux 上进行压测：jp@gc-Stepping Thread Group
生成的结果主要有：
1.监控 CPU/内存使用情况插件：jp@gc - PerfMon Metrics Collector
2.查看 tps 折线图插件：jp@gc - Transactions per Second
3.聚合报告
跟着文档做，测试结果是得到了，可是这些结果代表着什么呢？
下面是我的一些疑问
1.梯度加压的最大并发量是根据什么设定的呢?还是 10-20-...100 递增或递减？
2.监控 CPU、内存使用情况：内存是一条横线，有什么意义？CPU 维持在 80%-90% 之间代表什么？
3.平均 Tps 为 7048.0%，对数据库压测来说是高还是低？（肯定比接口测试要高了）
4.得到上述的压测结果后如何去进行分析？
5.我的测试场景是不是有缺失？测试步骤是否有问题？大家都是怎么做的？
期待大家留言！！
记录得挺详细的，点个赞。
关于你提的问题，按我目前了解尽量回答下：
1.梯度加压的最大并发量是根据什么设定的呢?还是 10-20-...100 递增或递减？
根据业务场景。比如秒杀场景，是一次性加压上去；如果是用户量逐渐增加的场景，一般是 10-20-30 这样增上去。梯度加压主要的目的是让系统的缓存机制能生效，这样压出来的结果相比没有梯度，会靠谱一些。
2.监控 CPU、内存使用情况：内存是一条横线，有什么意义？CPU 维持在 80%-90% 之间代表什么？
内存是一根横线，说明你这个场景里，系统资源里内存基本是一个相对恒定的值。CPU 保持在 80% 到 90% 说明 CPU 占用较高。综合看就是你这个场景下，系统进行的主要是计算密集型的逻辑。至于怎么判定这样的资源占用是否 OK，那就得结合你实际预计部署这个数据库服务的情况来判定了。
3.平均 Tps 为 7048.0%，对数据库压测来说是高还是低？（肯定比接口测试要高了）
首先，TPS 单位是没有% 的，TPS 是 Transactions per Second。至于是高还是低，需要你根据业务场景去评估，找项目组一起讨论沟通出一个基准值。没有基准值的情况下，这个很难评估。
附一个别人做得 mysql 的基准测试供参考：https://blog.csdn.net/qq_36357820/article/details/80079012
4.得到上述的压测结果后如何去进行分析？
性能分析的目标是找到什么原因导致性能没达到可满足业务需要的水平（目标值）。但你这里目标值都没有定下来，就直接去压，得到的只能是一个数据供以后参考（比如业务量增长到最后打到数据库 TPS 接近你这里的压测水平时，要考虑提前扩容啥的）。
5.我的测试场景是不是有缺失？测试步骤是否有问题？大家都是怎么做的？
首先，你的测试场景个人觉得是有点不够科学的。看似覆盖了增删改查 4 个场景，但里面没看出和这个 “数据库 mycat 分片” 的场景有什么关联。压测目的有点不大明确（到底是测试 mycat 数据库分片相比不分片性能提升的情况，还是测试新方案相比旧方案性能是否有提升，还是别的目的）。
如果是我，我会这么做：
1、先搞清楚压测的目的。个人理解应该最低要求是确认在典型业务场景中，新方案性能要高于旧方案，否则就没意义了。
2、根据压测目的设计测试方案。假如目的是上面说的新方案性能和旧方案对比，那首先需要评估实际业务使用上，数据库使用的典型场景是啥（最简单，执行频率 top10 的 sql 先拉出来看看，顺便也看看分片后 top10 的语句有多少获益），对应设计压测场景（频率高的、执行逻辑上会和分片关联比较大的，都需要纳入进来）。然后新老方案用一样的场景分别压一次，获取到两者的数据，再进行对比。
5.我的测试场景是不是有缺失？
“都需要测试哪些场景呢？”
开发回答：“增删改查”
呵呵，开发靠得住吗？
这年头还在用 mycat 呀
先回到测试的目的上来吧，为什么要用 mycat，现有的系统有什么性能问题，用 mycat 目的是解决哪些问题么？
要解决的这些问题是不是成为你的测试目标和场景？如果用 mycat，那关联业务上的热点是什么，是不是要评估？
高春琪
回复
从 0 到 1 是个突破的过程，有困难在所难免，俗话说 “万事开头难” 嘛
敢于尝试、勇于突破，后面会迎来自身全新的蜕变。
well done, man! 
记录得挺详细的，点个赞。
关于你提的问题，按我目前了解尽量回答下：
1.梯度加压的最大并发量是根据什么设定的呢?还是 10-20-...100 递增或递减？
根据业务场景。比如秒杀场景，是一次性加压上去；如果是用户量逐渐增加的场景，一般是 10-20-30 这样增上去。梯度加压主要的目的是让系统的缓存机制能生效，这样压出来的结果相比没有梯度，会靠谱一些。
2.监控 CPU、内存使用情况：内存是一条横线，有什么意义？CPU 维持在 80%-90% 之间代表什么？
内存是一根横线，说明你这个场景里，系统资源里内存基本是一个相对恒定的值。CPU 保持在 80% 到 90% 说明 CPU 占用较高。综合看就是你这个场景下，系统进行的主要是计算密集型的逻辑。至于怎么判定这样的资源占用是否 OK，那就得结合你实际预计部署这个数据库服务的情况来判定了。
3.平均 Tps 为 7048.0%，对数据库压测来说是高还是低？（肯定比接口测试要高了）
首先，TPS 单位是没有% 的，TPS 是 Transactions per Second。至于是高还是低，需要你根据业务场景去评估，找项目组一起讨论沟通出一个基准值。没有基准值的情况下，这个很难评估。
附一个别人做得 mysql 的基准测试供参考：https://blog.csdn.net/qq_36357820/article/details/80079012
4.得到上述的压测结果后如何去进行分析？
性能分析的目标是找到什么原因导致性能没达到可满足业务需要的水平（目标值）。但你这里目标值都没有定下来，就直接去压，得到的只能是一个数据供以后参考（比如业务量增长到最后打到数据库 TPS 接近你这里的压测水平时，要考虑提前扩容啥的）。
5.我的测试场景是不是有缺失？测试步骤是否有问题？大家都是怎么做的？
首先，你的测试场景个人觉得是有点不够科学的。看似覆盖了增删改查 4 个场景，但里面没看出和这个 “数据库 mycat 分片” 的场景有什么关联。压测目的有点不大明确（到底是测试 mycat 数据库分片相比不分片性能提升的情况，还是测试新方案相比旧方案性能是否有提升，还是别的目的）。
如果是我，我会这么做：
1、先搞清楚压测的目的。个人理解应该最低要求是确认在典型业务场景中，新方案性能要高于旧方案，否则就没意义了。
2、根据压测目的设计测试方案。假如目的是上面说的新方案性能和旧方案对比，那首先需要评估实际业务使用上，数据库使用的典型场景是啥（最简单，执行频率 top10 的 sql 先拉出来看看，顺便也看看分片后 top10 的语句有多少获益），对应设计压测场景（频率高的、执行逻辑上会和分片关联比较大的，都需要纳入进来）。然后新老方案用一样的场景分别压一次，获取到两者的数据，再进行对比。
陈恒捷
回复
感谢您的认真回复！
行动项：
1.确认系统典型场景，和开发确认执行频率 top10 的 sql
2.和项目组确定 tps 基准值、目标值
3.增加测试场景：测试 mycat 数据库不分片性能情况，和分片性能做对比
高春琪
回复
建议你的行动项里增加一个前置项：了解清楚压测的目的。
我说的新老对比，是假设目的已经明确是新老对比。你这里的目的至少从正文看，是不确定的。需要找给你分配任务的领导先沟通清楚这个目的，再做后面的事情。
方向不对，努力白费。在确认方向这件事情上不要含糊，不要凭自己主观推断，必须和任务分配人沟通清楚，最好是你自己按自己理解复述一遍并且分配人觉得没问题，这样来达成一致。要不后面事倍功半。
