排查压测问题引发的系统性能调优过程

前言：

今天测试部门的小梦找到我，委屈巴巴的说我写的接口有问题，因为她对这个接口进行压力测试时，发现系统的吞吐量一直上不去，并且 应用服务器 （部署接口项目的服务器） 的CPU、内存等资源的使用率也一直很低，导致一直无法测试出这个接口的压力峰值。

听小梦说完后，自己心想接口都测试了好几遍了，接口代码 绝对不可能有问题的，再说了，有问题也不能承认呀，看来得往别的地方上扯扯呀；然后我说道，接口应该是没问题的，可能是项目环境部署时有些参数没进行调优吧，例如：连接数大小设置、JVM参数设置、数据库参数优化等；

然后我接着说道，项目是谁给你部署配置的呀，小梦说是小王部署的，然后今天小王也没来上班；我说道，小王没来上班呀，没事，让我来，我这bug绝缘体质，任何问题遇到我都会退避三舍的。

上面的情景，我相信大家都可能会遇到过的；接下来我们就通过这次排查压测问题来聊聊一个 单体系统 的性能优化应该考虑哪些点，以及对这些点该怎么进行调优 。

本文主线如下图：

项目部署环境：

在进行这次压测问题排查前，先通过下图了解下 接口项目的情况、项目部署的环境、JMeter测试脚本 的配置情况；

上图中的接口项目、Redis、MySql 都是单机安装部署的 。

注意： 再进行下文之前，我们还需要记住一个前提：本项目中的接口代码是不存在问题的，并且数据库查询SQL都是最优的，都是走索引查询的，本次压力测试问题不是由于代码导致的，而是由于各种参数未调优造成的；代码调优和SQL调优在编码阶段就已经完成了。

简单性能调优的点：

在上文中的项目部署情况和测试脚本的配置情况下进行压力测试时，就出现了小梦说的系统吞吐量上不去，以及应用服务器（部署接口项目的服务器）的 CPU 等资源使用率都很低的情况；

查看 JMeter 测试时系统的吞吐量如下图：

查看应用服务器（部署接口项目的服务器）的CPU使用率很低：

按照测试脚本的50个并发以及接口中含有计算密集型操作（加解密和验签）的情况，CPU是不应该这么低的；哎！什么鬼嘛？

别急，下面我们就展开具体的排查过程，并在排查过程中逐步了解各个调优的点；

排查过程就是按照文章开头中的 本文主线 图片中 简单性能调优的点 展开的 。

排查Tomcat连接器参数配置：

Tomcat 连接器参数配置只需要考虑以下几个方面：

• Connector使用哪种 protocol 协议

  • HTTP/1.1：默认值，使用的协议与Tomcat版本有关

  • 建议使用 NIO2：org.apache.coyote.http11.Http11Nio2Protocol

  • 除了NIO2协议外，还有 BIO、NIO、APR 协议，可以自行去查阅资料；

• acceptCount：等待队列的长度；当等待队列中连接的个数达到acceptCount时，说明队列已满，再进来的请求一律被拒绝；默认值是100。

• maxConnections：Tomcat 在任意时刻接收和处理的最大连接数；

  • 当连接数达到最大值maxConnections后，Tomcat会继续接收连接，直到accept等待队列填满。

  • 如果最大连接数设置为-1，则表示禁用maxconnections功能，表示不限制tomcat容器的连接数；

  • 最大连接数默认值与连接器使用的 protocol 协议有关：

    • NIO的默认值是10000；
    • APR/native的默认值是8192；
    • BIO的默认值为maxThreads（如果配置了Executor，则默认值是Executor的maxThreads）；

• maxThreads：每一次HTTP请求到达 Tomcat，都会创建一个线程来处理该请求，那么最大线程数决定了Tomcat 可以同时处理多少个请求。

  • maxThreads 默认200;
  • 建议：maxThreads应该设置大些，以便能够充分利用CPU；当然，也不是越大越好，如果maxThreads过大，那么CPU会花费大量的时间用于线程的上下文切换，整体效率可能会降低；这需要根据自己项目的情况和服务器硬件配置情况配置合适的值即可；

下面就是本次压测时配置的Tomcat连接器参数：