一次压测经验过程的经验记录

开篇说明

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