前言

对于提供接口服务的应用程序，很多都使用 SpringBoot 默认的 Servlet 容器 Tomcat。上线之初，由于大部分流量较小，我们不会对 Tomcat 进行特殊的参数调整。随着流量的增加，应用的性能指标变得越来越差。这个时候我们大多数人都会选择扩容。除了扩容之外，我们还可以选择对 Tomcat 进行性能调优，在不增加成本的情况下提升性能。

Tomcat 架构

从上图可以看出，Tomcat 将其业务抽象为 Server、Service、Connector、Contner 等组件，每个组件都有不同的作用。 Server 组件是 Tomcat 的最外层组件，它是 Tomcat 实例本身的抽象，代表 Tomcat 本身。一个服务器组件可以有一个或多个服务组件。 Service 组件是 Tomcat 中提供服务和处理请求的一组组件。一个服务组件可以有多个连接器和一个容器。 Connector表示它可以使用多种协议同时接收用户请求。连接器负责处理客户端连接，它提供对各种服务协议的支持，包括 BIO、NIO、AIO 等，它存在的价值在于屏蔽多协议 Container 的复杂性，统一 Container 的处理标准。 Container 组件是负责具体业务逻辑处理的容器。当 Connector 组件与客户端建立连接时，它会将请求转发给 Container 组件的 Engine 组件进行处理。至此，Tomcat 的核心组件就基本完成了。 其实 Container 组件里面还有很多细分的组件。如果你对业务的抽象感兴趣的话，可以继续看下去。 可以看出，Host 是虚拟主机的抽象，Context 是应用程序的抽象，Wrapper 是 Servlet 的抽象，Engine 是处理层的抽象

核心参数

在了解核心参数之前，我们需要对 Tomcat 对于请求的处理流程有一个大概的了解。 Tomcat 对请求的处理流程如下： 在上面的示意图中，有三个非常关键的核心参数，这也是性能调优的关键。 从以上三个参数的含义，我们可以得知以下结论： 客户端并不直接与 Tomcat 的 Connector 组件建立联系，而是先与操作系统建立联系，然后交给Connector。这一点非常重要，否则你将无法理解该 acceptCount 参数。 不仅 Connector 组件中有一个队列，操作系统中也有一个队列来临时存储与客户端的连接，这也是一个关键点。 我们所说的线程池是指 Container 容器中的线程池。 理解这三个核心参数的含义非常重要，否则就没有办法进行后续的性能调优工作。

maxThreads

我们知道指的 maxThreads 是最大请求处理线程数，Tomcat7 和 Tomcat8 都是默认的 200。该参数的设置需要根据任务的执行内容进行调整。一般来说，计算公式为： 最大线程数 = ((IOtime+CPUtime)/CPUtime) CPU核心数 这个公式的思想其实很简单，就是最大化的利用 CPU 资源。任务的时间消耗分为 IO 时间消耗和 CPU 时间消耗。基本上 IO 时间消耗是最多的，此时 CPU 无事可做。所以如果可以让 CPU 在任务等待 IO 的同时处理其他任务，那么 CPU 利用率就会提高。一般来说，由于 IO 耗时远大于 CPU 耗时，所以 maxThreads 根据公式计算出来的数量会远大于 CPU 核数，这是正常的。 需要注意的是，这个值并不是越高越好。因为一旦线程过多，CPU 就需要进行上下文切换，消耗部分 CPU 资源。因此，最好的办法是利用上面的公式计算出一个基准值，然后进行压力测试调整到合理的值。一般来说，如果的值 maxThreads 增大，但吞吐量没有增加或减少，则可能表明已经达到瓶颈。

maxConnections

maxConnections 指当线程池中的线程达到最大值并且全部在忙时，Connector 中的队列可同时容纳的最大连接数。默认情况下，Tomcat 的 maxConnections 为 10000。一般来说，这个值不需要进行调整。如果服务器的资源非常充足，可以适当调大该值。

acceptCount

acceptCount 指当 Connector 队列满时，操作系统队列可以容纳的最大连接数。默认情况下，Tomcat 的 acceptCount 为 100。这个值对性能的影响非常大。如果太小，会导致客户端连接请求阻塞。如果太大，会导致操作系统资源耗尽。因此，这个值需要根据服务器的负载进行调整。

性能调优

根据以上介绍，我们可以进行以下调优： 调大 maxThreads：根据公式计算出一个基准值，然后进行压力测试调整到合理的值。 适当调大 maxConnections：如果服务器的资源非常充足，可以适当调大该值。 调大 acceptCount：根据服务器的负载，适当调大 acceptCount 的值。 除了上述参数外，还可以通过以下方式进行调优： 使用 NIO 连接器：相对于 BIO 连接器，NIO 连接器具有更高的性能。 启用 HTTP/2 协议：HTTP/2 协议可以提高吞吐量和降低延迟。 使用连接池：连接池可以减少创建和销毁连接的开销。 使用缓存：缓存可以减少对数据库的访问，从而提高性能。 优化 JVM 参数：JVM 参数可以对 Tomcat 的性能产生很大的影响。

总结

通过对 Tomcat 进行性能调优，我们可以显著提高应用程序的性能。在调优过程中，需要根据服务器的负载和业务特点进行调整。本文介绍了 Tomcat 的核心参数和调优方法，希望对大家有所帮助。

---

tomcat大神求教：8080,8009,8443,8005都是什么端口，apache与tomcat通信是靠8009端口

<Server port=8005 shutdown=SHUTDOWN> 远程停服务抄端口百<Connector port=8080 protocol=HTTP/1.1 connectionTimeout= redirectPort=8443 URIEncoding=UTF-8/> 其中度8080为知HTTP端口，8443为HTTPS端口<Connector port=8009 protocol=AJP/1.3 redirectPort=8443 /> 8009为AJP端口APACHE能过AJP协议访问TOMCAT得到8009端口。

Tomcat内存优化

Tomcat内存优化主要是对tomcat启动参数优化，我们可以在tomcat的启动脚本中设置JAVA_OPTS参数。

JAVA_OPTS参数说明

-server启用jdk的server版；

-Xmsjava虚拟机初始化时的最小内存；

-Xmxjava虚拟机可使用的最大内存；

-XX:PermSize内存永久保留区域

-XX:MaxPermSize内存最大永久保留区域

扩展资料：

Tomcat并发优化

连接相关参数

在Tomcat配置文件conf下面中的配置中和连接数相关的参数有：

minProcessors：最小空闲连接线程数，用于提高系统处理性能，默认值为10

maxProcessors：最大连接线程数，即：并发处理的最大请求数，默认值为75

acceptCount：允许的最大连接数，应大于等于maxProcessors，默认值为100

enableLookups：是否反查域名，取值为：true或false。为了提高处理能力，应设置为false

connectionTimeout：网络连接超时，单位：毫秒。设置为0表示永不超时，这样设置有隐患的。通常可设置为毫秒。

生产级基于SpringCloud微服务架构性能优化实战，建议收藏

本文将从 Tomcat性能优化，SpringCloud开启重试机制，Zuul网关性能参数优化，Ribbon性能参数优化，Feign与Hystrix性能优化等 五个方面分享在生产环境如何做好SpringCloud性能优化。

一般基于SpringCloud的微服务能够脱离传统的tomcat，独立跑起来，SpringBoot功不可没，其原理是SpringBoot内嵌了tomcat（当然可以换成其他servlet容器，如jetty），能够以java -jar形式就能跑起来。

所以针对每个springboot服务，我们需要对tomcat的一些参数进行优化，以下是楼主项目组优化的tomcat参数配置，供大家参考。

tomcat参数说明：

maxThreads，acceptCount参数应用场景

场景一

场景二

场景三

maxThreads调优

一般说服务器性能要从两个方面说起：

1、cpu计算型指标

2、io密集型指标

所以大部分情况下，tomcat处理io型请求比较多，比如常见的连数据库查询数据进行接口调用。

另外，要考虑tomcat的并发请求量大的情况下，对于服务器系统参数优化，如虚拟机内存设置和linux的open file限制。

maxThreads设置多大合适？

我们知道线程过多，会导致cpu在线程切换时消耗的时间随着线程数量的增加越来越大；线程太少，服务器的请求响应吞吐量会急剧下降，所以maxThreads的配置绝对不是越大越好。

实际情况是设置maxThreads大小没有最优解，要根据具体的服务器配置，实际的应用场景不断的调整和优化。

acceptCount设置多大合适？

尽量与maxThreads的大小保持一致 ， 这个值应该是主要根据应用的访问峰值与平均值来权衡配置的。

当使用URL进行路由时，则需要对-timeout-millis和-timeout-millis参数控制超时时间。

请求连接的超时时间

请求处理的超时时间

对所有操作请求都进行重试

对当前实例的重试次数，针对同一个服务实例，最大重试次数（不包括首次调用）

对下个实例的重试次数，针同其它的服务实例，最大重试次数（不包括首次server）

注意Hystrix断路器的超时时间需要大于ribbon的超时时间，不然不会触发重试

Feign和Ribbon在整合了Hystrix后，首次调用失败的问题？

目前楼主的强烈做法是： 禁用Hystrix的超时时间，设为false

还有一种是官方提倡的是 设置超时时间。

在实际的项目中亲测，这种方式也有不好的地方， 如请求时间超过5s会出现请求数据时有时无的情况 ，给用户的感觉是 系统不稳定，要求整改 。

另外，禁用hystrix，官方不推荐 。

hystrix超时设置原则

问题：一个http请求，如果feign和ribbon都配置了重试机制，异常情况下一共会请求多少次？

请求总次数 n 为feignClient和ribbon配置参数的笛卡尔积：

n(请求总次数) = feign(默认5次) * (MaxAutoRetries+1) * (MaxAutoRetriesNextServer+1)

其中+1是代表ribbon本身默认的请求。

其实二者的重试机制相互独立，并无联系。但是因为用了feign肯定会用到ribbon，所以feign的重试机制相对来说比较鸡肋，一般会关闭该功能。ribbon的重试机制默认配置为0，也就是默认是去除重试机制的，建议不要修改。