开篇说明
如果在这里获得过启发和思考，希望点赞支持！对于内容有不同的看法欢迎来信交流。
技术栈 >> java
邮箱 >> 15673219519@163.com
描述
通常对于QPS较高的web应用程序在开发完成后，除了功能测试之外还需要做一轮压力测试。这样的好处主要有以下几点，也是本次压测的目的
- 确保程序没有性能问题。
- 确定需要的使用资源，包括web服,DB资源,磁盘资源等等。
- 大致预估机器设配能够承受的压力，如：DB读写QPS等等
本次的压测目标（本次压测工具使用jemter）
| 接口类型 | 接口操作 | 预估OPS | 实际QPS | 峰值QPS |
|---|---|---|---|---|
| 只读接口 | redis get(1),tidb select(1) | 1w | 14983/s | - |
| 读写接口 | tidb select(1),update(1),insert(1) | 5k | 6022/s | - |
测试过程
-
压测时候最好使用内网地址，这样可以保证jemter达到最大请求数，提升资源使用率。
-
对于某些首次操作查询DB，之后查询走redis的。建议在前期去掉缓存，便于更好测试。后期基本测试结束可加上redis，再去估计缓存内存使用。
| 接口类型 | jemter并发 | pod/cpu使用/内存使用 | tidb-kv/cup使用/内存使用 | tidb-db/cup使用/内存使用 | redis/cup使用/内存使用 | db-连接池/初始化 | redis-连接池 | qps均值 | 结论 |
|---|---|---|---|---|---|---|---|---|---|
| redis get(1),db select(1) | 250 | C6-12G*3/ 50%/ 30% | C6*3/10% /20% | C6*3/10%/20% | C4-12G | 100 | 100 | 3920/s | 压力不足,加并发数 |
| 500 | C6-12G*3/ 90%/ 40% | C6*3/12% /20% | C6*3/11%/21% | C4-12G | 100 | 100 | 4950/s | padcup不足，加pad或pad加cup | |
| 1000 | C6-12G*6/ 40%/ 40% | C6*3/12% /22% | C6*3/11%/21% | C4-12G | 100 | 100 | 5230/s | 机器资源足够，qps上不去,加大连接数 | |
| 1000 | C6-12G*6/ 65%/ 50% | C6*3/25% /30% | C6*3/25% /30% | C4-12G | 500 | 200 | 10278/s | 压力不足,加并发数 | |
| 1500 | C6-12G*6/ 88%/ 60% | C6*3/30% /35% | C6*3/30% /35% | C4-12G | 500 | 200 | 14983/s | 6pod,可以达到我们只读QPS要求,接下次读写接口测试 | |
| tidb select(1),update(1),insert(1) | 500 | C6-12G*6/ 60%/ 50% | C6*3/60% /70% | C6*3/50% /50% | C4-12G | 500 | 200 | 3832/s | 压力不足,加并发数 |
| 1000 | C6-12G*6/ 92%/ 55% | C6*3/80% /80% | C6*3/60% /60% | C4-12G | 500 | 200 | 5102/s | 满足要求，可以继续测试DB极限，加pod，产生更多db操作 | |
| 1500 | C6-12G*8/ 80%/ 55% | C6*4/90% /85% | C6*3/80% /80% | C4-12G | 500 | 200 | 6022/s | db差不多到极限 | |
测试结果
- 需要达到要求的QPS，我们需要准备的机器资源 pod:C6-12G*8 tidb: db C6*4; kv C6*3, db:连接池最大连接500，redis最大连接200
- 需要注意的点：
- 在增加pod的时候，需要注意对db，redis的连接数需要保证，pod数*单个pod最大连接数<db的最大连接数，否则会导致db的效率大大降低。
- 程序的内存我们需要进入到pod中查看（java程序），通常看java heap, 老年代，新生代等接口。（没有大对象操作的情况下，java内存几乎达不到瓶颈）
- 大致可以得出结论：单个db:可以承受的qps 5000/s，通常情况下web程序的瓶颈在db这里，通过本次测试结果，我们就可以根据接口中对db的操作次数，大致需要多少的资源满足需求的qps。
优化程序
- 对于java，我们可以使用一些程序诊断工具，判断程序是否存在性能问题，或者是某个方法执行比较耗时；
- 本次我是用到arthas，生成火焰图的方式，看那些方法执行占用的cup比较长，从而定位到问题所在。（推荐arthas）
流程控制)
)
