〇,经验总结:
-
<李>如果在压测过程中,压力始终上不去,可以考虑是施压机器并发上不去,或者被压机器请求处理不过来。
<李>施压上不去或者被压机器请求处理不过来,是因为机器CPU瓶颈?内存瓶颈?端口数量瓶颈?逐步排查定位。
<李>类似于Grpc这类需要建立rpc连接的请求,可扩展端口的数量会影响并发时连接建立数量。
<李>长链路的压测链,在定位问题时可以先从短链开始逐步排查扩展到长链,最终完成整个链路的压力测试。
<李>关注压测过程中可能出现的异常现象,哪怕是很不明显的地方,都可能会存在一个BUG。
一、背景说明
这周我们对项目里新增的几个接口进行了压力测试,期间遇到了一些之前没有遇到过的坑,走了一些弯的路,在这里对这次压力测试经历进行总结复盘,同时也希望能给看到这篇文章的诸位提供一些浅显的思路。
首先介绍一下我们项目的结构。服务入口是一个网关模块,提供一个Grpc类型的接口,数据传输模式是一元数据模式。网关模块与其他业务模块之间通过达博接口进行交互。
服务的架构概况图如下:
该业务接口部署的服务器配置和部署MySQL组件的服务器配置一致,都是4核8 g, 50克普通硬盘,并且处于同一个内网网段,我们预估的性能指标要达到300并发,600 TPS。
在压力测试过程中,我们重点关注TPS, GC次数,CPU占用率和接口响应时间等指标。
二、测试过程
完成项目部署后,我们开始编辑jemeter测试脚本,设置压力测试的标准为300个并发线程,在10秒内全部启动,持续压测时间15分钟,接着开始启动jemeter脚本进行测试。
1,第一次压力测试
垃圾收集策略包括:老年代启用CMS垃圾收集算法,新生代启用ParNew垃圾收集算法,新生代最大存活周期为15次minorGC, FullGC时使用CMS算法,并开启CMS中的并行标记。
根据前几次的压力测试经验,我们将初始堆内存设置为2048 mb,因为偏小的堆内存设置容易在压力测试时被撑爆。
JVM内存分配:最大/最小堆内存为2048 mb,伊甸园和幸存者比例为,新生代和老年代的比例为1:2。由于服务器安装的是JDK8版本,废弃了永久代的配置。
JVM配置参数如下:
<代码> - xx: + PrintGCDetails - xx: + PrintGCDateStamps -Xloggc:/var/log/模块/gc.log美元 - xx: + UseConcMarkSweepGC - xx: + UseParNewGC - xx: MaxTenuringThreshold=15 - xx: + ExplicitGCInvokesConcurrent - xx: + CMSParallelRemarkEnabled - xx: + HeapDumpOnOutOfMemoryError - xx: HeapDumpPath=/var/log/$模块 -Xmx2048m -Xms2048m - xx: SurvivorRatio=8
(2)性能指标监控
高级命令观察java线程的CPU占用率(我们表示用户进程,sy表示系统进程),并使用jstac -gcutil Pid 1000命令,定期查看虚拟机的GC情况。
一切准备就绪后,我们开始跑压测脚本,并查看性能监控指标。
但是我们没有看到预期来临的压力,而是并发到达一定值时,好像突然并发压力中断了,然后间隔1 - 2秒后压力又重新出现,这期间接口服务器各项指标均没有异常。很显然,并发存在问题!
(3)问题排查与解决
上述压测过程中出现的现象,可以细分为两类:
-
<李>并发数量没有达到预期值,而且徘徊在一个较低水平,压测2分钟,接口侧只收到3 w多了个请求,实际在施压服务器尝试发起了7 w次请求。
<李>并发过程中出现类似压力中断的现象,而且并非偶然现象,压力停顿之后压测脚本中的断言开始抛出错误信息:连接异常。
异常信息如下:
由于Grpc接口需要在客户端与服务端建立RPC连接,那么两端都需要同时指定各自的一个端口进行数据通信。基于这一点,我们判断出现第一种现象的原因可能有两个:
-
<李>施压机器端口受限,没有启动足够的线程发起请求;李
<李>被压机器端口受限,不能接收施压机器发过来的所有请求连接,导致连接请求丢失。
而出现第二种现象的原因,可能正是由于端口数量受限,并发线程不能正常发起,需要等待连接端口释放后才能继续发起新的连接线程。
