SpingBoot项目之性能压测并提高并发访问量（一）

一般项目上线之前，除了我们的测试之外，其实性能压测也是必要并且很关键的一部分，这样会避免我们线上当遇到大的访问量的时候，项目请求无法响应或者响应超时的问题。

解决这种大的并发问题，提高我们项目的访问量一直是我们项目性能经常需要探讨的一个问题，高并发的结局并不是无脑的扩容服务器，应该针对具体问题做出合适的性能优化策略。下面我会通过一个小案例来提高他的访问量

说到性能压测，我们都离不开jmeter,如何使用，下面先做一个简单的讲解：

我们以最简单，最常用的为例。一般我们会用到jmeter的四部分来做压测工作：

1）线程组：模拟我们多线程多次请求

2）http请求：真正测试的http请求

3）查看结果树：详细的http请求信息成功与否

4）据合报告：根据据合报告分析性能，失败了多少，吞吐量是多少等等

新建线程组

线程组上新建http请求，测试我们的请求uri

这里需要注意：因为我们测试的是接口或者说是请求地址的性能，为了避免请求之间建立连接和关闭连接的耗时，我们需要长连接来避免这部分的性能损耗，所以【基本】里面需要勾选【KeepAlive】,【高级】里面的客户端实现需要选择【java】

我们简单的一个压测测试，只请求一次，返回成功

对应的而聚合报告：

好了上面介绍完jmeter的使用，下面我们来压测我们项目，并看一下是如何发现项目接口的性能瓶颈的

 

1）首先linux启动我们的项目，先查看一下当前默认springBoot中维护了多少个线程

查看一下我们运行的java程序的pid

ps -ef  | grep java

查看我们springBoot项目内嵌的tomcat默认维护的线程总数量

pstree -p java的pid | wc -l

当我们的jmeter进行压测，模拟500个线程，10秒，循环100次的时候，最大线程数涨到了221，已经是极限

 2）在我们的springBoot内嵌的tomcat的配置文件中有一些我们需要注意和优化的参数

可以找到【spring-configuration-metadata.json】文件，所有搜索【server.tomcat】节点的都是关于tomcat的默认配置的，下面我们注意关注以下几个参数：

2.1）server.tomcat.accept-count:等待队列长度，默认100；

当我们的tomcat连接用完，所有的多余的请求会被放到这个等待队列中，若是放满默认的100个还有多余的请求，则会请求报错

2.2）server.tomcat.max-connections:最大被连接数，默认10000

2.3）server.tomcat.max-threads:最大的工作线程数，默认200

2.4）server.tomcat.min-spare-threads:最小的工作线程数，默认10

 

结合上面的一些默认配置我们需要根据我们测试的性能瓶颈进行修改，我们对配置文件做出如下修改

server.tomcat.accept-count=1000
server.tomcat.max-connections=10000
server.tomcat.max-threads=800
server.tomcat.min-spare-threads=100

 

 

 （默认经验来说，一个4核8G内存的服务器，最大线程数800较为合适，最小工作线程数为100较为合适）

然后我们重启我们的项目，可以看到，我们默认情况下tomcat总的线程数变为了121个

我们再次进行压测,可以看到我们的总线程数量达到了821个，比优化之前将近扩充了4倍，大大提高了我们的并发访问能力

好了，我们的简单的一个并发数的提升优化至此结束。

除此之外，我们springboot内嵌tomcat并没有对keepAlive参数做任何优化，说到keepAlive,这里先做一个简单的介绍：

当我们的客户端请求服务器的时候在请求头上带上了我们的keepalive，就代表我们的客户端需要和服务器端保持长久的连接，也就是服务器对客户端做完响应不要立刻断开连接，而是保持连接可以复用连接来减少断开重连时间的消耗问题；http1.0之前没有此参数，也就是http都是无状态的短链接，因为cpu资源的稀缺；现在加上此参数，是因为现在的很多应用程序都需要频繁的与服务器做交互请求，因此需要做长连接请求；但是也有一些问题，如果不做限制，无限等待，会有恶意攻击（如dos攻击），那么我们网站也是不安全的，所以需要对此参数要做出相应的一些配置

 

所以我们需要对keeAlive也应该做一下定制化的配置，一来避免频繁建联带来的性能消耗，二来避免长时间连接无限等待带来的恶意损耗。主要配置如下两个参数：

keepAliveTimeOut:多少毫秒后不响应的断开keepalive

maxKeepAliveRequest:多少次请求后keepalive断开失效

我们通过config配置类来进行相关配置，因为内嵌tomcat并没有暴露相关keepAlive的配置

新建一个配置类，具体内容如下：

//当Spring容器内没有TomcatEmbeddedServletContainerFactory这个bean时，会吧此bean加载进spring容器中
@Component
public class WebServerConfiguration implements WebServerFactoryCustomizer<ConfigurableWebServerFactory> {
    @Override
    public void customize(ConfigurableWebServerFactory configurableWebServerFactory) {
            //使用对应工厂类提供给我们的接口定制化我们的tomcat connector
        ((TomcatServletWebServerFactory)configurableWebServerFactory).addConnectorCustomizers(new TomcatConnectorCustomizer() {
            @Override
            public void customize(Connector connector) {
                Http11NioProtocol protocol = (Http11NioProtocol) connector.getProtocolHandler();

                //定制化keepalivetimeout,设置30秒内没有请求则服务端自动断开keepalive链接
                protocol.setKeepAliveTimeout(30000);
                //当客户端发送超过10000个请求则自动断开keepalive链接
                protocol.setMaxKeepAliveRequests(10000);
            }
        });
    }
}

 

类中注释了配置参数的含义，不再多介绍。至此我们tomcat部分的优化到此结束

 

 

抛出问题，当我再压测的时候，我通过【top -H】命令看到了如下服务性能情况：

我们的cpu几乎快要达到百分之一百，而【load average】的平均一分钟达到7.57，而且主要性能耗费在mysql数据库上

后面我们会陆续讲述我们利用redis的缓存机制来减轻mysql数据库的压力，使其性能再次做一个提升