二、高并发治理：2、Tomcat运行环境优化

一、前言

Tomcat 版本

• 注意不同版本差异性，本文以Tomcat 8.0 版本为例
  Tomcat 8.0 版本之后，引入了 Executor 接口作为 Tomcat 线程池的核心组件。 多个Connector可以使用同一个线程池来处理请求。

二、Tomcat连接和线程池原理

池化技术是一种常用的提升性能的手段，比如常见的数据库连接池、JAVA字符串的常量池、以及线程池等。

以JAVA中的线程为例，创建一个新线程的背后，其实是调用操作系统的api，消耗宝贵的系统资源，去执行一些业务逻辑。

如果我们频繁的创建销毁线程对象，对于CPU、内存都是一个很大的负担。

所以，线程池就应运而生了。本质上，池化技术是一种以空间换时间的做法。

• 请求数 小于 服务最大数，直接进入服务区

标题图1：Tomcat连接池工作原理

• 请求数，大于服务最大数，开始排队

标题图2：Tomcat连接池工作原理-排队

• tomcat拒绝后，调用掉可以看到如下报错

Connection reset by peer
Closing connection 0

tomcat catalina.out日志 异常信息为“java.util.concurrent.RejectedExecutionException

三、Tomcat Executor 并发参数配置

• 官网参考配置 https://tomcat.apache.org/tomcat-8.5-doc/config/executor.html
• 参考默认连接池配置:

<Executor name="tomcatThreadPool" namePrefix="catalina-exec-"
          maxThreads="150" minSpareThreads="4"/>

3.1 生产真实配置样例

<Executor
          name="tomcatThreadPool"
          namePrefix="product-tomcat-threadPool-exec-"
          maxThreads = "600"
          maxSpareThreads = "300"
          minSpareThreads = "250"
          maxIdleTime = "60000" 
          prestartminSpareThreads="true"
          maxQueueSize="1000"/>

3.2 一张图看懂线程池工作原理 

 

参数说明

• name: 线程池名称.
• namePrefix: 创建的每个线程的名称前缀, 单独的线程名称为 namePrefix + threadNumber.
• maxThreads :Tomcat 使用线程来处理接收的每个请求，这个值表示 Tomcat 可创建的最大的线程数，默认值是 200，因为机器配置是8C16G，且几乎所有接口 TP999 RT20ms，所以配置的maxThreads = "600"，建议这个配置的机器，最大线程数少于800
• minSpareThreads：最小空闲线程数，Tomcat 启动时的初始化的线程数，表示即使没有使用也开这么多空线程等待，默认值是 10。这个一定要改，因为一旦并发量变大，开启线程需要耗费大量时间，开启线程期间会有大量超时和报错。建议改为100以上，我们根据日常请求计算，放在250个
• maxSpareThreads：最大备用线程数，一旦创建的线程超过这个值，Tomcat 就会关闭不再需要的 socket 线程。因为日常我们计算平稳时间，通常在300以内，所以设置为300
• maxIdleTime: 线程最大空闲时间, 超过该时间后, 空闲线程会被销毁, 默认值为6000, 单位为毫秒. 非常及时的销毁，也会在业务波动时，带来较大的时间开销，不建议设置过小，我们设置为6万毫秒
• prestartminSpareThreads: 是否在启动程序时就生成minSpareThreads个线程, 默认为false, 即不启动. 若不设置为true, 则minSpareThreads的设置就不起作用了
• maxQueueSize: 最大的等待队列数, 超过则拒绝请求. 默认值为int类型的最大值(Integer.MAX_VALUE), 等同于无限大. 一般不作修改, 避免发生部分请求未能被处理的情况

四、Tomcat connector的并发参数配置

• 参考官网配置说明 https://tomcat.apache.org/tomcat-8.5-doc/config/http.html >> Connectors部分
• 默认的配置, 生产不建议使用

 <Service name="Catalina">
  <!--The connectors can use a shared executor, you can define one or more named thread pools-->
  <!--
    <Executor name="tomcatThreadPool" namePrefix="catalina-exec-"
        maxThreads="150" minSpareThreads="4"/>
    -->
  <Connector port="8080" protocol="HTTP/1.1"
               connectionTimeout="20000"
               redirectPort="8443"
               maxParameterCount="1000"
               />

• 线上场景还原

单机 QPS 3W-10W 
90% 接口TP99 RT 20ms
机器配置8C16G
代码逻辑中70%外部查询（含DB\REDIS\RPC）+30本地逻辑处理

4.1 生产真实配置如下，注意不懂参数不要随意加

<Connector executor="tomcatThreadPool" port="8080"
		protocol="org.apache.coyote.http11.Http11Nio2Protocol"
		maxThreads="600"
		maxConnections="10000"
		acceptCount="2048"

		connectionTimeout="15000"
		keepAliveTimeout="30000"
		maxHttpHeaderSize="16384"

		URIEncoding="UTF-8"
		maxKeepAliveRequests="512"
		
		compression="on"
		compressionMinSize="4096"
		noCompressionUserAgents="gozilla, traviata"
		compressableMimeType="text/html,text/xml,text/javascript,text/css,text/plain,
application/json,application/x-javascript"/>

4.2 Connector 参数protocol

• protocol 默认值是HTTP/1.1，它使用自动切换机制来选择基于Java NIO的连接器或基于APR/native的连接器。但不建议这样配置。为了使用显式协议而不是依赖于上述自动切换机制，可以使用以下值：
  • • org.apache.coyote.http11.Http11NioProtocol - non blocking Java NIO connector org.apache.coyote.http11.Http11Nio2Protocol - non blocking Java NIO2 connector org.apache.coyote.http11.Http11AprProtocol - the APR/native connector.
    • 从官网摘录，协议的差异和对tomcat版本支持
      • Tomcat 8 下使用 NIO2, 即 org.apache.coyote.http11.Http11Nio2Protocol 更优

 

Tomcat的3种 BIO\NIO\APR模式，简单对比如下：
BIO - 同步阻塞IO模式
BIO, 同步阻塞IO, 性能低, 没有经过任何优化处理和支持.
服务器实现模式为一个连接一个线程, 即客户端有连接请求时服务器端就需要启动一个线程进行处理, 如果这个连接不做任何事情会造成不必要的线程开销, 当然可以通过 线程池 机制改善.
适用场景: BIO方式适用于连接数比较小且固定的架构, 这种方式对服务器资源要求比较高, 有并发局限, JDK1.4之前的唯一选择.

NIO - 同步非阻塞IO模式
是Java SE 1.4及后续版本提供的一种新的IO操作方式(即java.nio包及其子包). Java NIO是一个基于缓冲区、并能提供非阻塞IO操作的Java API, 因此NIO也被看成是non-blocking IO(非阻塞式IO)的缩写, 它拥有比传统BIO操作更好的并发性能.
服务器实现模式为一个请求一个线程, 即客户端发送的连接请求都会注册到多路复用器上, 多路复用器轮询到连接有IO请求时才启动一个线程进行处理.
适用场景: 适用于连接数较多且连接比较时间短(轻操作)的架构, 比如聊天服务器. 这种方式的并发性能局限于应用中, 编程比较复杂.
目前Tomcat 8.x默认运行在NIO模式下.

APR - 可移植运行时模式
APR(Apache Portable Runtime, Apache可移植运行时), 是Apache HTTP服务器的一个支持库, 它提供了一组映射到底层操作系统的API, 如果操作系统不支持特定功能, APR库将提供仿真. 因此开发人员可以使用APR使程序真正跨平台移植.
此模式的安装步骤比较繁琐, 但却从操作系统层面解决了异步IO的问题, 能大幅度提高应用性能.
APR的本质是使用 JNI 技术调用操作系统底层的IO接口, 所以需要提前安装必要的依赖.

4.3 Connector 参数 executor

executor="tomcatThreadPool" 使用自定义线程池处理 使用自定义线程池处理

4.4 Connector 参数 maxConnections

maxConnections ，使用了NIO2，默认值10000

服务器在任何给定时间将接受和处理的最大连接数。当达到这个数字时，服务器将接受但不处理另一个连接。此附加连接将被阻止，直到正在处理的连接数降至maxConnections以下，此时服务器将再次开始接受和处理新连接。请注意，一旦达到限制，操作系统仍然可以接受基于acceptCount设置的连接。默认值因连接器类型而异。对于NIO和NIO2，默认值为10000。对于APR/native，默认值为8192

4.5 Connector 参数 maxThreads、minSpareThreads

• maxThreads="600" 表示最多同时处理X个连接,默认值是200（Tomcat 7、8都是）
  • 如果Connector绑定了Executor，这个值会被忽略。因为我们设置绑定了线程池，这个值与线程池线程大小一致
    maxThreads规定的是最大的线程数目，并不是实际running的CPU数量；实际上，maxThreads的大小比CPU核心数量要大得多。这是因为，处理请求的线程真正用于计算的时间可能很少，大多数时间可能在阻塞，如等待数据库返回数据、等待硬盘读写数据等。因此，在某一时刻，只有少数的线程真正的在使用物理CPU，大多数线程都在等待；因此线程数远大于物理核心数才是合理的。 Tomcat通过使用比CPU核心数量多得多的线程数，可以使CPU忙碌起来，大大提高CPU的利用率。 应用中CPU越不密集（IO越密集），maxThreads应该越大，以便能够充分利用CPU。当然，maxThreads的值并不是越大越好，如果maxThreads过大，那么CPU会花费大量的时间用于线程的切换，整体效率会降低。
• minSpareThreads：Tomcat连接器初始化 socket 的线程数，我们指定了executor ，所以不配置该参数
  • 如果未指定，则使用默认值10。如果关联executor，则会忽略此属性。因为将使用executor而不是内部线程池执行任务。 请注意，如果配置了executor，则为该属性设置的值，任然会被被正确记录，但它将被报告（例如通过JMX）为-1，以表明它没有被使用。

4.6 Connector 参数 acceptCount

• acceptCount: 当同时连接的人数达到maxConnection时,开始排队,队列大小为该配置，超过队列长度就主动拒绝其他连接
• 当达到maxConnections时，操作系统为传入连接请求提供的队列的最大长度。 操作系统可能会忽略此设置，并对队列使用不同的大小。 当此队列已满时，操作系统可能会主动拒绝其他连接，或者这些连接可能会超时。默认值为100。

4.7 Connector 参数 maxHttpHeaderSize

maxHttpHeaderSize 提供maxHttpRequestHeaderSize和maxHttpResponseHeaderSize的默认值。如果未指定，此属性将设置为8192（8 KiB）

4.8 Connector 压缩参数

压缩参数，监听端口队列最大数，满了之后客户请求会被拒绝，默认值100（不能小于maxSpareThreads ）

compression="on" 打开压缩功能
compressionMinSize="2048"启用压缩的输出内容大小，默认为2KB
noCompressionUserAgents="gozilla,traviata" 对于以下的浏览器，不启用压缩
compressableMimeType="text/html,text/xml,text/javascript,text/css,text/plain"　哪些资源类型需要压缩

• Tomcat 的压缩是在客户端请求服务器对应资源后，从服务器端将资源文件压缩，再输出到客户端，由客户端的浏览器负责解压缩并浏览。相对于普通的浏览过程 HTML、CSS、Javascript和Text，它可以节省40% 左右的流量。更为重要的是，它可以对动态生成的，包括CGI、PHP、JSP、ASP、Servlet,SHTML等输出的网页也能进行压缩，压缩效率也很高。

五、Tomcat 连接数和线程数要匹配

5.1 连接过多，处理线程不足时

5.2 连接和线程匹配时 

5.3 maxThreads如何配置

• CPU密集型和IO密集型对比
  • 一般的服务器操作都包括量方面：1 CPU计算密集（主要消耗cpu），2 IO密集（io、数据库等）
  • 第一种极端情况，如果我们的操作是纯粹的计算，那么系统响应时间的主要限制就是cpu的运算能力，此时maxThreads应该适当减小，降低同一时间内争抢CPU的线程个数，可以提高计算效率，提高系统的整体处理能力。
  • 第二种极端情况，如果我们的操作纯粹是IO或者数据库，那么响应时间的主要限制就变为等待外部资源，此时maxThreads应该尽量设的大，这样才能提高同时处理请求的个数，从而提高系统整体的处理能力。此情况下因为tomcat同时处理的请求量会比较大，所以需要关注一下tomcat的虚拟机内存设置和linux的open file限制。

六、总结 Tomcat 线程池和 JDK 线程池

• 区别
  • 配置方式：Tomcat 线程池的配置通常与 Tomcat 的连接器相关联，而 JDK 线程池是以编程方式或者使用配置类进行配置的。
  • 使用场景：Tomcat 线程池主要用于处理 Web 请求，而 JDK 线程池通常用于一般的并发任务处理。
• 关联性：
  • 每个连接器可以有自己的线程池，这意味着在 Tomcat 中，可以有多个线程池在不同的连接器之间工作。而 JDK 线程池是全局的，通常在应用程序中只有一个线程池实例。