tomcat性能优化

tomcat 的关键指标有吞吐量、响应时间、错误数、线程池、CPU 以及 JVM 内存。

server.xml优化

其实网络的tomcat配置信息的文章很多，五花八门，一般推荐使用tomcat自身提供的配置帮助文档，因为你只要下载了tomcat,并且启动了它，那么tomcat就会提供最官方，最准确的官方参数说明文档。

下载tomcat后不要删掉默认的程序包.

一般tomcat启动后，不改动端口的话，默认是8080,我们输入localhost:8080 访问下。

这个会出现一个英文的tomcat环境界面，包括各种文档说明信息都在此，我推荐使用谷歌浏览器，因为这个浏览器自带翻译功能。

Connector连接器

IO模型优化策略

连接器模式改为NIO模式,NIO模式最大化压榨了CPU，把时间片更好利用起来,NIO适合大量长连接。

I/O 调优实际上是连接器类型的选择，一般情况下默认都是 NIO，在绝大多数情况下都是够用的，除非你的 Web 应用用到了 TLS 加密传输，而且对性能要求极高，这个时候可以考虑 APR，因为 APR 通过 OpenSSL 来处理 TLS 握手和加 / 解密。OpenSSL 本身用 C 语言实现，它还对 TLS 通信做了优化，所以性能比 Java 要高。

那你可能会问那什么时候考虑选择 NIO.2？我的建议是如果你的 tomcat 跑在 Windows 平台上，并且 HTTP 请求的数据量比较大，可以考虑 NIO.2，这是因为 Windows 从操作系统层面实现了真正意义上的异步 I/O，如果传输的数据量比较大，异步 I/O 的效果就能显现出来。

如果你的 tomcat 跑在 Linux 平台上，建议使用 NIO，这是因为 Linux 内核没有很完善地支持异步 I/O 模型，因此 JVM 并没有采用原生的 Linux 异步 I/O，而是在应用层面通过 epoll 模拟了异步 I/O 模型，只是 Java NIO 的使用者感觉不到而已。因此可以这样理解，在 Linux 平台上，Java NIO 和 Java NIO.2 底层都是通过 epoll 来实现的，但是 Java NIO 更加简单高效。

最大线程优化策略

maxThreads属性设置为简单200.这对于单个核心计算机来说很好，但是可以根据生产计算机上的处理器数量线性增加。在具有四个处理器的计算机上，将此值设置为800到1000之间的任何值都不会导致问题。如果配置的数量最终远远超过所需的线程数，则当服务器负载较低时，线程池将自然缩减此数字。

压缩gzip连接器传输

客户端和服务器之间的任何主要是文本的通信，无论是HTML，XML还是简单的Unicode，都可以使用简单的标准GZIP算法定期压缩高达90％。这可以对减少网络流量产生巨大影响，允许响应更快地发送回客户端，同时允许更多网络带宽可用于其他网络繁重的应用程序。

<Connector port="80" protocol="HTTP/1.1"
      connectionTimeout="20000"
      redirectPort="8443" executor="tomcatThreadPool" URIEncoding="utf-8"
            compression="on"
            compressionMinSize="50" noCompressionUserAgents="gozilla, traviata"
            compressableMimeType="text/html,text/xml,text/javascript,text/css,text/plain" />

配置线程池 Executor

<Executor 
    name="tomcatThreadPool"<!--线程名称-->
    namePrefix="catalina-exec-"
    maxThreads="150"<!--最大处理连接数线程-->
    minSpareThreads="4" /><!--保留最少线程数-->
<!-- 将原有的Connector 替换为带有线程池的Connector如下,其实servlet.xml已经有了,只要打开就可以了,将原来的去掉  -->
<Connector 
    executor="tomcatThreadPool"
    port="8080"
    protocol="HTTP/1.1"
    connectionTimeout="20000"
    redirectPort="8443"
    minProcessors="5"<!-- 同时处理请求的最小数 -->
    maxProcessors="75"<!-- 同时处理请求的最大数 -->
    acceptCount="1000" /><!-- 接受最大并发数量 ,超过这个数量就会返回连接被拒绝 -->

Executor的属性

这里面最核心的就是如何确定 maxThreads 的值，如果这个参数设置小了，tomcat 会发生线程饥饿，并且请求的处理会在队列中排队等待，导致响应时间变长；如果 maxThreads 参数值过大，同样也会有问题，因为服务器的 CPU 的核数有限，线程数太多会导致线程在 CPU 上来回切换，耗费大量的切换开销。

那 maxThreads 设置成多少才算是合适呢？为了理解清楚这个问题，我们先来看看什么是利特尔法则（Little’s Law）。

利特尔法则

系统中的请求数 = 请求的到达速率 × 每个请求处理时间

其实这个公式很好理解，我举个我们身边的例子：我们去超市购物结账需要排队，但是你是如何估算一个队列有多长呢？队列中如果每个人都买很多东西，那么结账的时间就越长，队列也会越长；同理，短时间一下有很多人来收银台结账，队列也会变长。因此队列的长度等于新人加入队列的频率乘以平均每个人处理的时间。

计算出了队列的长度，那么我们就创建相应数量的线程来处理请求，这样既能以最快的速度处理完所有请求，同时又没有额外的线程资源闲置和浪费。

假设一个单核服务器在接收请求：

如果每秒 10 个请求到达，平均处理一个请求需要 1 秒，那么服务器任何时候都有 10 个请求在处理，即需要 10 个线程。
如果每秒 10 个请求到达，平均处理一个请求需要 2 秒，那么服务器在每个时刻都有 20 个请求在处理，因此需要 20 个线程。
如果每秒 10000 个请求到达，平均处理一个请求需要 1 秒，那么服务器在每个时刻都有 10000 个请求在处理，因此需要 10000 个线程。

因此可以总结出一个公式：

线程池大小 = 每秒请求数 × 平均请求处理时间

这是理想的情况，也就是说线程一直在忙着干活，没有被阻塞在 I/O 等待上。实际上任务在执行中，线程不可避免会发生阻塞，比如阻塞在 I/O 等待上，等待数据库或者下游服务的数据返回，虽然通过非阻塞 I/O 模型可以减少线程的等待，但是数据在用户空间和内核空间拷贝过程中，线程还是阻塞的。线程一阻塞就会让出 CPU，线程闲置下来，就好像工作人员不可能 24 小时不间断地处理客户的请求，解决办法就是增加工作人员的数量，一个人去休息另一个人再顶上。对应到线程池就是增加线程数量，因此 I/O 密集型应用需要设置更多的线程。

线程 I/O 时间与 CPU 时间

至此我们又得到一个线程池个数的计算公式，假设服务器是单核的：

线程池大小 = （线程 I/O 阻塞时间 + 线程 CPU 时间）/ 线程 CPU 时间

其中：线程 I/O 阻塞时间 + 线程 CPU 时间 = 平均请求处理时间

对比一下两个公式，你会发现，平均请求处理时间在两个公式里都出现了，这说明请求时间越长，需要更多的线程是毫无疑问的。

不同的是第一个公式是用每秒请求数来乘以请求处理时间；而第二个公式用请求处理时间来除以线程 CPU 时间，请注意 CPU 时间是小于请求处理时间的。

虽然这两个公式是从不同的角度来看待问题的，但都是理想情况，都有一定的前提条件。

请求处理时间越长，需要的线程数越多，但前提是 CPU 核数要足够，如果一个 CPU 来支撑 10000 TPS 并发，创建 10000 个线程，显然不合理，会造成大量线程上下文切换。
请求处理过程中，I/O 等待时间越长，需要的线程数越多，前提是 CUP 时间和 I/O 时间的比率要计算的足够准确。
请求进来的速率越快，需要的线程数越多，前提是 CPU 核数也要跟上。

实际场景下如何确定线程数

那么在实际情况下，线程池的个数如何确定呢？这是一个迭代的过程，先用上面两个公式大概算出理想的线程数，再反复压测调整，从而达到最优。

一般来说，如果系统的 TPS 要求足够大，用第一个公式算出来的线程数往往会比公式二算出来的要大。我建议选取这两个值中间更靠近公式二的值。也就是先设置一个较小的线程数，然后进行压测，当达到系统极限时（错误数增加，或者响应时间大幅增加），再逐步加大线程数，当增加到某个值，再增加线程数也无济于事，甚至 TPS 反而下降，那这个值可以认为是最佳线程数。

线程池中其他的参数，最好就用默认值，能不改就不改，除非在压测的过程发现了瓶颈。如果发现了问题就需要调整，比如 maxQueueSize，如果大量任务来不及处理都堆积在 maxQueueSize 中，会导致内存耗尽，这个时候就需要给 maxQueueSize 设一个限制。当然，这是一个比较极端的情况了。

再比如 minSpareThreads 参数，默认是 25 个线程，如果你发现系统在闲的时候用不到 25 个线程，就可以调小一点；如果系统在大部分时间都比较忙，线程池中的线程总是远远多于 25 个，这个时候你就可以把这个参数调大一点，因为这样线程池就不需要反复地创建和销毁线程了。

接下来我们看看 tomcat 两个比较关键的参数：maxConnections 和 acceptCount。在解释这个参数之前，先简单回顾下 TCP 连接的建立过程：客户端向服务端发送 SYN 包，服务端回复 SYN＋ACK，同时将这个处于 SYN_RECV 状态的连接保存到半连接队列。客户端返回 ACK 包完成三次握手，服务端将 ESTABLISHED 状态的连接移入accept 队列，等待应用程序（tomcat）调用 accept 方法将连接取走。这里涉及两个队列：

半连接队列：保存 SYN_RECV 状态的连接。队列长度由net.ipv4.tcp_max_syn_backlog设置。
accept 队列：保存 ESTABLISHED 状态的连接。队列长度为min(net.core.somaxconn，backlog)。其中 backlog 是我们创建 ServerSocket 时指定的参数，最终会传递给 listen 方法：
```
int listen(int sockfd, int backlog);
```
如果我们设置的 backlog 大于net.core.somaxconn，accept 队列的长度将被设置为net.core.somaxconn，而这个 backlog 参数就是 tomcat 中的acceptCount参数，默认值是 100，但请注意net.core.somaxconn的默认值是 128。你可以想象在高并发情况下当 tomcat 来不及处理新的连接时，这些连接都被堆积在 accept 队列中，而acceptCount参数可以控制 accept 队列的长度，超过这个长度时，内核会向客户端发送 RST，这样客户端会触发上文提到的“Connection reset”异常。

而 tomcat 中的maxConnections是指 tomcat 在任意时刻接收和处理的最大连接数。当 tomcat 接收的连接数达到 maxConnections 时，Acceptor 线程不会再从 accept 队列中取走连接，这时 accept 队列中的连接会越积越多。

maxConnections 的默认值与连接器类型有关：NIO 的默认值是 10000，APR 默认是 8192。

所以你会发现 tomcat 的最大并发连接数等于maxConnections + acceptCount。如果 acceptCount 设置得过大，请求等待时间会比较长；如果 acceptCount 设置过小，高并发情况下，客户端会立即触发 Connection reset 异常。

去除valve访问tomcat记录

<Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs"
               prefix="localhost_access_log" suffix=".txt"
               pattern="%h %l %u %t "%r" %s %b" />

关闭自动重载，热部署方式

关闭自动重载，默认是true(不同版本中有差异),自动加载增加运行开销并且很容易内存溢出

web.xml优化

去掉不必要的servlet

如当前应用是REST应用(微服务)：

去掉不必要的资源：JspServlet
seesion也可以移除

JspServlet优化

checkInterval - 如果“development”属性为false且“checkInterval”大于0，则使用后台编译。“checkInterval”是查看JSP页面(包括其附属文件)是否需要重新编译的两次检查时间间隔（单位：秒）。缺省值为0秒。
classdebuginfo - 类文件在编译时是否显示调试(debugging)信息？ true 或false，缺省为true。
classpath - 编译servlet时要使用的类路径，当ServletContext 属性org.apache.jasper.Constants.SERVLET_CLASSPATH未设置的情况下，该参数才有效。在tomcat中使用到Jasper时，该属性总被设置。缺省情况下，该路径基于你当前的web应用动态生成。
compiler – Ant将要使用的JSP页面编译器，请查阅Ant文档获取更多信息。如果该参数未设置，那么默认的Eclipse JDT Java编译器将被用来代替Ant。没有缺省值。
compilerSourceVM - 编译源文件时采用哪一个JDK版本？(缺省为 JDK 1.4)
compilerTargetVM - 运行类文件时采用哪一个JDK版本？(缺省为 JDK 1.4)
development - 是否让Jasper用于开发模式？如果是，检查JSPs修改的频率，将通过设置modificationTestInterval 参数来完成。true 或false，缺省为true。
displaySourceFragment - 异常信息中是否包含出错的源代码片段？true 或false，缺省为true。
dumpSmap - JSR45调试的SMAP信息是否转存到文件？true 或false，缺省为false。当suppressSmap 为true时，该参数为false。
enablePooling - 确定是否共享标签处理器，true或false，缺省为true。
engineOptionsClass - 允许指定的类来配置Jasper。如果没有指定，则使用默认的Servlet内置参数(EmbeddedServletOptions)。
errorOnUseBeanInvalidClassAttribute - 在一个useBean action中，当类属性的值不是一个合法的bean class时，Jasper是否抛出异常？true或false，缺省为true。
fork - 是否让Ant派生出JSP页面多个编译，它们将运行在一个独立于tomcat的JVM上。true 或者false, 缺省为true.
enStringAsCharArray - 是否把字符串转换为字符数组？在某些情况下会改善性能。缺省为false.
eClassId - 当使用标签时，发送给Internet Explorer的class-id的值。缺省为：8AD9C840-044E-11D1-B3E9-00805F499D93。
javaEncoding - 生成java源文件时采用的Java文件编码。缺省为UTF-8。
keepgenerated - 是否保存每个页面生成的java源代码，而不删除。true 或 false，缺省为true。
mappedfile - 是否对每个输入行都用一条print语句来生成静态内容，以方便调试。true 或 false，缺省为true。
modificationTestInterval - 检查JSP页面修改的间隔时间（单位：秒），在间隔时间内，JSP及其包含的页面将不会检查。当间隔时间为0时，JSP每一次访问都会被检查。仅仅适用于开发模式（参数development为true）。缺省为4秒。从JSP每次开始访问开始计时，N秒以后检查，变化就编译，每次访问都刷新开始时间，默认4秒
scratchdir - 当编译JSP页面时使用的scratch 目录。缺省为当前WEB应用的工作目录。
suppressSmap - 是否禁止JSR45调试时生成SMAP信息？true 或 false，缺省为false。
trimSpaces - 是否去掉模板文本中行为和指令之间的空格。缺省为false。
xpoweredBy - 确定生成的Servlet是否加上X-Powered-By 响应头？true 或 false，缺省为false。

tomcat版本升级

jvm优化

set "JAVA_OPTS= -server -Xms4096M -Xmx4096M  -Xss512k -XX:+AggressiveOpts -XX:+UseBiasedLocking  -XX:+DisableExplicitGC -XX:MaxTenuringThreshold=15 -XX:+UseConcMarkSweepGC -XX:+UseParNewGC  -XX:+CMSParallelRemarkEnabled -XX:+UseCMSCompactAtFullCollection -XX:LargePageSizeInBytes=128m -XX:+UseFastAccessorMethods -XX:+UseCMSInitiatingOccupancyOnly -Djava.awt.headless=true"