Tomcat性能调优

Posted 2021-08-30 JavaEdge.

由于Web应用程序跑在Tomcat工作线程，因此Web应用对请求的处理时间也直接影响Tomcat性能，而Tomcat和Web应用在运行过程中所用到的资源都来自os，因此调优需要将服务端看作是一个整体来考虑。

• I/O调优指选择NIO、NIO.2还是APR
• 线程池调优指的是给Tomcat的线程池设置合适的参数，使得Tomcat能够又快又好地处理请求

I/O模型

I/O调优实际上是连接器类型的选择，一般情况下默认都是NIO，在绝大多数情况下都是够用的。

APR

除非你的Web应用用到了TLS加密传输，而且对性能要求极高，这个时候可以考虑APR，因为APR通过OpenSSL来处理TLS握手和加/解密。OpenSSL本身用C语言实现，它还对TLS通信做了优化，所以性能比Java高。

NIO.2

若你的Tomcat跑在Windows，且HTTP请求的数据量较大，可考虑NIO.2。因为Windows从os实现了真正的异步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更简单高效。

线程池调优

跟I/O模型紧密相关的是线程池，线程池的调优就是设置合理的线程池参数。

• Tomcat线程池的关键参数：
  

如何确定maxThreads：

• 若该参数设置小了
  Tomcat会发生线程饥饿，并且请求的处理会在队列中排队等待，导致响应时间变长
• 若过大
  因为服务器的CPU的核数有限，线程数太多会导致线程在CPU上来回切换，耗费大量的切换开销。

maxThreads多少合适呢？

利特尔法则

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

去超市结账排队，如何估算一个队列有多长呢？

• 队列中如果每个人都买很多东西，那么结账的时间就越长，队列也会越长
• 短时间一下有很多人来收银台结账，队列也会变长

因此队列的长度等于 新人加入队列的频率 乘以 平均每个人处理的时间。

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

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

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

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

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

理想情况，线程一直在忙着干活，没有被阻塞在I/O等待。

实际上任务在执行中，线程不可避免会发生阻塞，比如阻塞在I/O等待上，等待DB或下游服务响应，虽然通过非阻塞I/O模型可减少线程的等待，但是数据在用户空间和内核空间拷贝过程中，线程还是阻塞。
线程一阻塞就会让出CPU，线程闲置下来，就好像工作人员不可能24h处理请求，解决办法就是增加工作人员数量，一个人去休息另一个人顶上。即增加线程数，因此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个，这个时候你就可以把这个参数调大一点，这样线程池就不需反复创建和销毁线程。

调优很多时候是在找系统瓶颈

假如有个状况：系统响应比较慢，但CPU的用率不高，内存有所增加，通过分析Heap Dump发现大量请求堆积在线程池的队列中，请问这种情况下应该怎么办呢？

应该怀疑大量线程被阻塞了，应该看看web应用是不是在访问外部数据库或者外部服务遇到了延迟。