开篇说明
如果在这里获得过启发和思考,希望点赞支持!对于内容有不同的看法欢迎来信交流。
技术栈 >> 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)