36 | Tomcat I/O和线程池的并发调优
李号双
该思维导图由 AI 生成，仅供参考
上一期我们谈到了如何监控 Tomcat 的性能指标，在这个基础上，今天我们接着聊如何对 Tomcat 进行调优。
Tomcat 的调优涉及 I/O 模型和线程池调优、JVM 内存调优以及网络优化等，今天我们来聊聊 I/O 模型和线程池调优，由于 Web 应用程序跑在 Tomcat 的工作线程中，因此 Web 应用对请求的处理时间也直接影响 Tomcat 整体的性能，而 Tomcat 和 Web 应用在运行过程中所用到的资源都来自于操作系统，因此调优需要将服务端看作是一个整体来考虑。
所谓的 I/O 调优指的是选择 NIO、NIO.2 还是 APR，而线程池调优指的是给 Tomcat 的线程池设置合适的参数，使得 Tomcat 能够又快又好地处理请求。
I/O 模型的选择
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 的效果就能显现出来。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
Tomcat的性能调优涉及到I/O模型和线程池的优化。在选择I/O模型时，一般情况下默认使用NIO，但在特定情况下可以考虑使用NIO.2或APR。对于线程池调优，需要合理设置maxThreads参数，以避免线程饥饿或过多线程导致的性能问题。利特尔法则提供了一个理论计算线程池大小的公式，但在实际场景中，需要通过压测和迭代来确定最佳线程数。此外，还需要注意其他线程池参数的调整，如maxQueueSize和minSpareThreads。文章强调了在实际调优过程中需要找到系统瓶颈，并提出了一个问题，引发读者思考。整体而言，本文介绍了Tomcat的I/O和线程池调优的相关知识，并提供了一些实际场景下的调优建议。
仅可试看部分内容，如需阅读全部内容，请付费购买文章所属专栏
《深入拆解 Tomcat & Jetty 》，新⼈⾸单¥68
《深入拆解 Tomcat & Jetty 》，新⼈⾸单¥68
立即购买
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(25)
- 最新
- 精选
QQ怪猜测请求处理时间过长，应该增大线程池线程数量作者回复: 这种情况应该怀疑大量线程被阻塞了，应该看看web应用是不是在访问外部数据库或者外部服务遇到了延迟
2019-08-03224
nightmare查看调用的服务是不是耗时太长作者回复: 对的
2019-08-037- 门窗小二老师！第二种I/O时间与CPU时间这两个指标如何查看？2019-08-0518
coder可能是线程池设置太小，可以先查看当前线程数，线程的状态(线程都在干嘛，是blocked还是wait/time wait),然后去看为什么会这样，blocked是否发生了锁未释放，wait/time wait是否是下游服务导致2020-09-235
草戊〈因此队列的长度等于新人加入队列的频率乘以平均每个人处理的时间。〉我觉得这句话有问题，举例说明，一分钟五个人加入排队，二分钟处理一个人，则按公式队列长度为十个人。假设过了十分钟，加入排队人数为50人，处理完人数为5人，队列还有45人则对。那么这个队列的长度，实际上指的是？应该是平均每分钟的到达队伍长度。 利特尔法则为：在一个稳定的系统中，长时间观察到的平均顾客数量L，等于长时间观察到的有效到达速率λ与平均每个顾客在系统中花费的时间之乘积，即L = λW2019-08-173- 芒夏Linux选择NIO，与操作系统有关，线程池压力测试寻找最优的最大线程数2020-03-162
- 月如钩需要排查下外部服务或者数据库连接2019-08-052
James程序如何统计io阻塞，cpu时间？ 请求总时间是可以统计到。 那io阻塞的时间是调用数据库等io操作的时间？2021-03-251
倔强CPU使用率很低，cpu load很高，任务在排队，是不是可以直接调大tomcat线程数2024-03-08归属地：上海
悟空聊架构假如有个状况：系统响应比较慢，但 CPU 的用率不高，内存有所增加，通过分析 Heap Dump 发现大量请求堆积在线程池的队列中，请问这种情况下应该怎么办呢？ 这种情况一般是磁盘 I/O 获网络 I/O 操作太慢了，或者是访问第三方接口太慢了。 1、可以先排查 I/O 操作为什么慢，比如是否有慢 SQL，是否有大量的读写文件、是否有大量的网络操作或网络不畅通问题。 2、如果是第三方接口太慢了，可以先让第三方系统进行排查，如果第三方解决不了，再继续往下看。 3、如果这些请求不需要同步返回请求结果，那可以选用异步操作，引入消息队列进行解耦，线程池中的线程就可以将请求丢到消息队列，然后线程回收到线程池。 2、2023-01-18归属地：广东
收起评论
