从应用的角度讲讲Tomcat的三大参数 maxThreads、acceptCount、maxConnections

Tomcat实战参数理解

---

前言

这几天因为公司项目搞活动，导致接口的请求负载非常高，甚至有些接口会直接报连接超时，所以研究了下Tomcat的一些参数原理，最主要有三个参数（从业务出发）

---

一、首先讲讲三大参数的含义

（1）maxThreads，这个网上有很多文章都有描述，顾名思义就是tomcat的接收请求的线程池的核心线程数，也可以理解成Java线程池的工作线程，默认是200，可以适当的进行调高。

个人经验想法：这几天用Jemeter进行压测，调高了测试服务器的这个参数，但是并没有收到成效，个人想法这个参数不是说调高了你的程序就能更快的处理请求了，这个跟你的Java程序启动分配了多少内存有关（正常情况下开启一个线程会需要相应的内存跟上），同时也受你的Cpu所限制，因为Cpu在做线程上下文切换的时候需要损耗性能，个人认为正常情况下就默认200就好了，除非你的服务器是性能很强劲（核数高，内存大），则可以选择加到400 - 800之间，引用网上文章的这句话 线程数的经验值为：1核2g内存，线程数经验值200；4核8g内存，线程数经验值800

（2）acceptCount，这个参数颇有争议，引用网上的一段话：
我之前也以为是工作线程满后，如果还有请求进来，则会进入等待队列，这个参数代表等待队列的阈值，这次我重新测试了一遍，发现并不是

首先我把核心线程设置成2，等待队列设置成1，然后每个在处理请求的地方睡眠一下（让工作线程被占据）

然后用jemeter发起4个请求，如果按照网上说的，或者我之前理解的，那么第四个请求应该会被拒绝，但是并没有，虽然时间漫长，但是4个请求都能完整的走完，所以我斗胆在这里下个定义，这个参数根本不是工作线程用完后，任务进入等待队列的阈值（先看下一个参数）

（3）maxConnections，这个参数也没有争议，最大连接数，我把tomcat的这个参数设置成1的时候发现就算用Jemeter发起多个请求，由于我在处理请求的方法设置了睡眠，虽然都要排队慢慢走完（过程缓慢），说明这个参数就是代表Tomcat所能接收的最大请求。看了下官网的介绍，在BIO模式下面，这个默认与MaxThread相等，而在NIO模式下面，这个默认值是10000，如果Tomcat是8以上的话，默认使用NIO模式，那么这个值就是10000了，也就是能接收1w个请求)
之所以讲这个参数是因为在看acceptCount的时候，有一篇文章里面讲到原文地址https://www.cnblogs.com/crazymakercircle/p/11748214.html

maxConnection满后，acceptCount才能起作用，再次我同样持怀疑的态度写程序试了下

如果这套理论是成立的话，预期的结果是第三个请求会被拒绝（实验结果确实会被拒绝）

所以这里我重新总结了下acceptCount，只有在Tomcat达到maxConnections后，后面的请求才会进入等待队列进行等待（是这个阈值）（可能Tomcat底层有一个组件与之对应），并不是指工作线程满后所进入的那个等待处理队列的阈值，所以通常情况下是1w，如果Tomcat总共接收不到1w个请求，这个参数无需优化。

二、如何调优

• 调优首先得看你自己的服务器配置，如果服务器配置较好，压测的时候（我这边是200并发）cpu的使用情况没有用到50%的情况下，可以适当增加这个maxThreads。
• 如果用户请求不在意等待时间的情况下，也可以适当增加acceptCount的值，能够在接收大大量请求的时候，让请求排队而不是抛弃（不过这个从个人理解上是治标不治本的方法，还是想办法增加处理速度）
• 基于上面的分析我这边由于服务器是双核的，在接收200并发的情况下，服务器会达到瓶颈，所以我这边向公司申请多一台服务器，组成一个小集群的结构，这样就能增加处理请求的速度。
• *个人经验之谈，在使用集群架构的同时，如果你的数据库的原因导致的接口处理慢，这样你就要考虑数据库的性能瓶颈的问题（这块不在这里做探讨），所以再考虑引入集群架构的时候要想清楚是程序处理导致的接口响应慢还是数据库的性能瓶颈、慢Sql之类的导致的接口响应慢。

三、总结

从实战的角度探讨这三个重点参数到这里就结束了，关于Tomcat调优这块还是挺多东西要学，欢迎大家一起讨论和学习。