网站建设中如何设置外链接,wordpress朋友圈图片不显示,兰州工业发展建设有限公司网站,爱站工具查询前面我们看了提高Tomcat启动速度的措施#xff0c;这里我们看一下如何提高Tomcat的性能。
Tomcat 的调优涉及 I/O 模型和线程池调优、JVM 内存调优以及网络优化等#xff0c;今天我们来聊聊 I/O 模型和线程池调优#xff0c;由于 Web 应用程序跑在 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 的效果就能显现出来。
如果你的 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 会发生线程饥饿并且请求的处理会在队列中排队等待导致响应时间变长如果 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 个这个时候你就可以把这个参数调大一点因为这样线程池就不需要反复地创建和销毁线程了。 今天我们学习了 I/O 调优也就是如何选择连接器的类型以及在选择过程中有哪些需要注意的地方。
后面还聊到 Tomcat 线程池的各种参数其中最重要的参数是最大线程数 maxThreads。理论上我们可以通过利特尔法则或者 CPU 时间与 I/O 时间的比率计算出一个理想值这个值只具有指导意义因为它受到各种资源的限制实际场景中我们需要在理想值的基础上进行压测来获得最佳线程数。
参考
本文参考了李号双老师的文章。
