Tomcat性能调优

Tomcat网络处理线程模型

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

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

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	20s	减少
maxThreads 处理连接的最大线程数	200	增加	不是越大越好
acceptCount(backlog)等待接收accept的请求数量限制	100	增加	socket参数,min(accept/proc/sys/net/core/somaxconn)
maxConnections 最大连接数	nio=10000 apr=8192	不变

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;  /**  * @author pangbohuan  * @date 2020/7/16 0016 16:23  * @description  */ @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不停地在工作,根本没法去处理那么多请求

总结

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

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

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

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

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

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

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

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