记一次Grpc接口压力测试&性能调优

〇、经验总结：

• 如果在压测过程中，压力始终上不去，可以考虑是施压机器并发上不去，或者被压机器请求处理不过来。
• 施压上不去或者被压机器请求处理不过来，是因为机器CPU瓶颈？内存瓶颈？端口数量瓶颈？逐步排查定位。
• 类似于Grpc这类需要建立rpc连接的请求，可扩展端口的数量会影响并发时连接建立数量。
• 长链路的压测链，在定位问题时可以先从短链开始逐步排查扩展到长链，最终完成整个链路的压力测试。
• 关注压测过程中可能出现的异常现象，哪怕是很不明显的地方，都可能会存在一个BUG。

一、背景说明
这周我们对项目里新增的几个接口进行了压力测试，期间遇到了一些之前没有遇到过的坑，走了一些弯路，在这里对这次压力测试经历进行总结复盘，同时也希望能给看到这篇文章的诸位提供一些浅显的思路。
首先介绍一下我们项目的结构。服务入口是一个网关模块，提供一个Grpc类型的接口，数据传输模式是一元数据模式。网关模块与其他业务模块之间通过Dubbo接口进行交互。
服务的架构概况图如下：

该业务接口部署的服务器配置和部署MySQL组件的服务器配置一致，都是4核8G，50G普通硬盘，并且处于同一个内网网段，我们预估的性能指标要达到300并发，600TPS。
在压力测试过程中，我们重点关注TPS、GC次数、CPU占用率和接口响应时间等指标。

二、测试过程
完成项目部署后，我们开始编辑jemeter测试脚本，设置压力测试的标准为300个并发线程，在10秒内全部启动，持续压测时间15分钟，接着开始启动jemeter脚本进行测试。
1、第一次压力测试
垃圾收集策略包括：老年代启用CMS垃圾收集算法，新生代启用ParNew垃圾收集算法，新生代最大存活周期为15次minorGC，FullGC时使用CMS算法，并开启CMS中的并行标记。
根据前几次的压力测试经验，我们将初始堆内存设置为2048MB，因为偏小的堆内存设置容易在压力测试时被撑爆。