Tomcat性能优化，学会薪水翻倍

时间:2022-07-25
本文章向大家介绍Tomcat性能优化，学会薪水翻倍，主要内容包括其使用实例、应用技巧、基本知识点总结和需要注意事项，具有一定的参考价值，需要的朋友可以参考一下。

Tomcat网络处理线程模型

tomcat是我们在web开发过程中会用到的servlet容器，同时也是springBoot内置集成默认的容器

所以我们有必要去了解它的网络线程模型

关注公-众-号：IT老哥，获取300G java学习资料

BIO+同步Servlet

tomcat8之前默认是BIO+同步Servlet的方式

执行流程是步骤是

  1. 用户请求
  2. nginx负责接收并转发到tomcat
  3. Tomcat具体使用的是BIOConnector 交由具体的Servlet
  4. Servlet处理业务逻辑

这是典型的BIO操作，相信大家如果对NIO和Netty有所了解的话对于这种线程模型不会陌生了

一个请求对应一个工作线程它的CPU利用率很低，所以新版本就不会使用这种方式了

tomcat8中默认是NIO的处理方式

APR+异步Servlet

这种方式用得不是特别多的，但是也还算比较常见

apr(Apache Portable Runtime/Apache可移植运行库)是Apache HTTP服务器的支持库

JNI的形式调用Apache HTTP服务器的核心动态链接库，来处理文件读取或网络传输操作

Tomcat默认监听指定路径，如果有apr安装，则自动启用

它借助更底层的JNI形式获取到更高的性能，在实际的工作中使用是比较麻烦的

因为我们还得去维护一个动态链接库，用的比较多的还是NIO的方式

NIO+异步Servlet

Tomcat8开始默认NIO方式，非阻塞读取请求信息非阻塞处理下一个请求，完全异步

NIO处理流程

  1. 接收器接收套接字
  2. 接收器从缓存中检索nioChannel对象
  3. Pollerthread将nioChannel注册到它的选择器IO事件
  4. 轮询器将nioChannel分配给一个work线程来处理请求
  5. SocketProcessor完成对请求的处理返回

Tomcat参数调优（理论）

tomcat参数调优有四个主要的参数，同时它也是三个调优的方向

ConnectionTimeout

是一种处理的超时机制，可以理解为是tomcat自我保护的机制

如果说这个请求长时间处理没有结束，Tomcat会认为这个请求处理超时

一般来说会根据项目的业务指标去调整

如果能处理很多请求那就把它调大一些

如果业务规定了用户请求最大的处理时间，那就把它对应调整一下

maxThreads

tomcat的处理能力可以理解为吞吐量

如果想在一秒内处理更多的请求，就可以调大这个参数

但是并非越大越好

acceptCount

操作系统底层的连接数，超过之后tomcat能接收的请求数(maxConnections)，请求堆积在操作系统的数量(windows和Linux略有不同)

操作系统专门有一个队列，用来保存应用程序还没来得及处理的请求

操作系统本身也有设置，操作系统会根据两个配置比较取一个最小值

当Tomcat设置100而操作系统设置90，操作系统会选择用90作为操作系统的连接数

maxConnections

tomcat的最大连接数，这个参数决定tomcat能接收多少个连接

但是并非设置了以后程序就能处理那么多请求

具体能处理多少或者说能处理多快由业务代码决定

一个tomcat总共能受理的最大连接数理论上= acceptCount+maxConnections

对于tomcat的处理能力需要调整maxThreads最大线程数量

对于tomcat参数调优不能靠经验猜测，需要通过不断调试，才能找出合适应用程序的合理配置

调优实操演示

环境准备

接下来我们会用到jmeter测试工具做测试，一般我们平时对于接口性能测试的时候会用到jmeter

连接数调整

我们先看处理一个请求完整过程

1. 一个用户的请求过来

2. 如果是windows它首先会进入一个accept队列，accept队列存放的是tcp三次握手完成的请求
   如果是linux它首先会进入到SYN队列进行三次握手，握手成功后再放入accept队列
 
3. 进入accept队列之后，tomcat中的selector会监听操作系统底层的事件通知，
   根据maxConnections大小限制接收客户连接，
   tomcat最大受理连接满了就会堆积到操作系统层面，
   windows最大受理连接也已经满了就会拒绝本次连接，
   linux却不仅仅是只有accept队列它还有SYN队列，它也会往SYN队列堆积一    些请求
   
   而这个SYN队列属于系统内核的一般来说我们不会对它做调整，
   当SYN队列也满了以后就会拒绝本次连接
 
4. tomcat收到请求以后读取该请求的数据，解析HTTP报文

5. 解析完以后，交由work处理线程池调用具体的Servlet执行业务代码，
   当maxThread满了以后会堆积到work处理线程池中
    
6. 执行完业务代码以后响应客户端

那么什么时候需要调整connections？如何调整？

当connections小于maxThread的时候需要调大，最好是比预期的最高并发数要大20%

maxThread大于connections的时候会将请求堆积到到tomcat的work处理线程池中(堆积占用内存)

什么时候需要调整acceptCount？如何调整？

想受理更多用户请求却又不想堆积在tomcat中，可以利用操作系统的处理队列来高效的堆积，可以调整为 最高并发数 - connections

实际上这个参数不需要调整，tomcat默认100，linux默认128，最好是把连接控制交给应用程序这样更方便管理

以springBoot框架快速建构一个tomcat容器的web应用，测试接口准备3个，控制器代码如下

package com.controller;

import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RestController;

import java.util.Random;
import java.util.concurrent.Callable;

@RequestMapping("/demo/")
@RestController
public class DemoController {

  @GetMapping("hello")
  public String hello() throws InterruptedException {
    // 这个方法固定延时3秒，用于测试线程/连接数量控制
    Thread.sleep(3000);
    return "hello!!";
  }

  @GetMapping("test")
  public String benchmark() throws InterruptedException {
    System.out.println("访问test：" + Thread.currentThread().getName());
    // 这段代码，一直运算
    for (int i = 0; i < 200000; i++) {
        new Random().nextInt();
    }
    // 50毫秒的数据库等待，线程不干活
    Thread.sleep(50L);
    return "Success";
  }

  @GetMapping("testAsync")
  public Callable<String> benchmarkAsync() {
    return new Callable<String>() {
      public String call() throws Exception {
        System.out.println("访问testAsync：" + Thread.currentThread().getName());
        // 这段代码，一直运算
        for (int i = 0; i < 200000; i++) {
            new Random().nextInt();
        }
        // 50毫秒的数据库等待，线程不干活
        Thread.sleep(50L);
        return "Success";
      }
    };
  }
}

然后把代码打成jar包，以jar包的方式运行

connections 设置为1

maxThreads 设置为1

acceptCount 设置为1

命令如下:

java -jar tomcatDemo.jar --server.tomcat.max-connections=1 --server.tomcat.max-thread=1 --server.tomcat.acceptCount=1

从理论上来说该程序最多能接受两个请求(connections+acceptCount)，我们来看一下到底是不是这样

打开jmeter测试工具，配置测试用例

配置1秒发送10个请求

windows测试结果

可以看到运行结果，在windows操作系统下，10请求只成功了2个，有8个被拒绝连接。

因为connections和acceptCount都设置为1，所有只能处理2个请求

linux测试结果

前面说到在linux系统中会有所不同，因为linux会在SYN队列堆积一些三次握手过程中的请求，所以它的受理请求应该是 (connections + acceptCount + SYN队列容量)

究竟是不是这样呢？我们来测试一波看下

同样的命令在linux启动

java -jar tomcatDemo.jar --server.tomcat.max-connections=1 --server.tomcat.max-thread=1 --server.tomcat.acceptCount=1 --server.port=9090

将jmeter测试用例中http请求地址，改成linux服务器中的地址

在linux环境下10个请求受理了9个，只有1个失败的

这也就证明了，之前说到的linux中不只根据(connections + acceptCount)的总数对连接数进行限制

它还有一个SYN队列用于保存三次握手过程中的请求，所以理论上来说它会比windows受理的请求更多一些

并发连接数调整

对于tomcat中最大线程数的调整需要注意两个点

  • 线程太少，CPU利用率过低，程序的吞吐量变小，资源浪费，容易堆积
  • 线程太多，上下文频繁切换，性能反而变低

那么我们该如果调整这个数量呢？

场景

服务器配置1核，不考虑内存问题，收到请求，java代码执行耗时50ms，等待数据返回50ms，总共耗时100ms

理想的线程数量 = (1 + 代码阻塞时间 / 代码执行时间) * cpu数量

这个公式是怎么得来的，下面举个例子

深圳某一个小区招聘保安，而保安亭里面只能够坐一个人，也就是说同一时间内只有一个保安在保安亭，
目前暂定每个保安每隔30分钟出去巡逻一次，每次巡逻30分钟
那么这时候应该请几个保安来合适呢？

最低也得两个，
因为保安亭无时无刻都要留一个保安守着，方便给小区的业主开门
而这个保安不可能分身去巡逻，所以还得再招聘一个保安进行轮流换班
所以理论值等于(1 + 保安坐着的时候 / 保安巡逻的时间) * 保安亭数量

我们的测试服务器为1核，所以理想的线程数量为 (1 + 50/50) * 1 = 2

实际情况是跑起代码，压测环境进行调试。不断调整线程数将CPU打到80~90%的利用率

linux启动命令

将最大线程数量启动为100

java -jar tomcatDemo.jar --server.tomcat.max-thread=100 --server.port=9090

配置jmeter测试用例

HTTP请求接口为：116.7.249.34:9090/demo/test

线程数为：1秒请求100个线程同时请求循环1次

吞吐量为1秒处理5个左右，异常请求达到51个

这是不是因为调太小了呢，要不要调大一点呢?

我们调整成500看一下

java -jar tomcatDemo.jar --server.tomcat.max-thread=500 --server.port=9090

配置jmeter测试用例

HTTP请求接口为：116.7.249.34:9090/demo/test

线程数为：1秒请求100个线程同时请求循环1次

点击运行，查看汇总报告

吞吐量为1秒处理5个左右，异常请求达到45个

加大线程以后异常数变少了，但是吞吐量还是不变，这是为什么呢.我们明明将最大线程数调成了500了，为什么会处理不过来呢

我们查看结果树看一下，什么原因报错

为什么会连接超时，默认不是20秒吗，这个接口怎么会执行了20秒

接着往下看，用表格查看结果

发现错误的请求确实是因为超过了20秒导致的连接超时

为什么会超过20秒？我们看下正常的请求是多少

第一个请求是85毫秒，为什么越往后的请求执行时间越长呢?

前面说到线程太多，上下文频繁切换，性能反而变低显然是对的。线程加开太多，CPU处理不过来只能变慢

那么我们就把线程数调小一些，让CPU处理不那么频繁

我们调整成10看一下

java -jar tomcatDemo.jar --server.tomcat.max-thread=10 --server.port=9090

点击运行，查看汇总报告

吞吐量为1秒处理5个左右，异常请求达到60个

这可怎么办呢?调大了不行，调小了也不行，无论怎么调得到的测试结果几乎差不多

我们看一下请求接口的这段代码

@GetMapping("test")
public String benchmark() throws InterruptedException {
  System.out.println("访问test：" + Thread.currentThread().getName());
  // 这段代码，一直运算
  for (int i = 0; i < 200000; i++) {
      new Random().nextInt();
  }
  // 50毫秒的数据库等待，线程不干活
  Thread.sleep(50L);
  return "Success";
}

20万次循环，不停的生成随机数。这个接口导致CPU不停地在工作，所以根本没法去处理那么多请求，所以在牛B的配置，遇到垃圾代码也没用。

总结

不要过度地去在意或者说是追求高并发，高处理能力，高吞吐量

换一个思维，先将接口的响应速度提高，剩下的再交给服务器配置

以一台8核16G的服务器为例，如果想要在一秒钟之内处理1000个请求，该怎么做呢？

1000个请求分发到8个CPU身上，每个CPU平均需要处理多少请求?
1000 / 8 = 125
1个CPU在1000毫秒内需要处理125个请求，那么最多允许接口响应速度是多少?
1000 / 125 = 8

想要一秒钟以内处理1000个请求，接口响应速度需要在8毫秒以内，也就是说必须小于8毫秒

因为这只是算上正常的CPU处理时间，还没算上网络连接延时耗时 、GC回收停止用户线程耗时

请求多CPU占用率高了，如果能接受很慢的响应，就加大线程数加大连接超时时间，否则就集群分流

认清现实，优化代码才是王道，配置只能是锦上添花！但是得知道这个花要怎么去添，这些参数代表什么意思，得怎么去调整

来源于：https://juejin.im/post/6850418121258303501

随机文章
本站知识点必读
最近更新