怎样肯定 Web 应用程序的线程池大小

怎样肯定 Web 应用程序的线程池大小

标签（空格分隔）： Thread Pool Web

---

本文原文是 How To Determine Web Application Thread Pool Size

继续当扩展 Web 应用程序时面临的架构问题，在这篇博客中，我将介绍一个常见的问题，怎样肯定 Web 应用程序的线程池大小？当部署 Web 应用程序到生产或是当 Web 应用程序性能测试的时候会显示出来。

线程池

在 Web 应用程序中，线程池大小决定了它们能在任什么时候候处理的并发请求数。若是一个 Web 应用程序获得的请求比线程池多，多余的请求要么排队要么被拒绝。

请注意并发并非并行。并发请求是在任什么时候间点只有少数请求能够运行在 CPU 上正在被处理的请求数。并行请求是在任什么时候间点全部的请求均可以运行在 CPU 上的正在处理的请求数。

在非阻塞 I/O 应用程序中，好比 NodeJS，一个单进程（线程）能处理并发的处理多个请求。在多核 CPU 环境，能够经过增长进程或线程数来处理并行请求。

在阻塞 I/O 应用程序中，好比 Java SpringMVC，一个单进程仅仅能够并发的处理一个请求。为了并发的处理更多的请求，咱们不得不增长线程数。

CPU 限制的应用程序

CPU 限制的应用程序，线程池的大小应该等于系统里面 CPU 的数量。增长更多的线程将中断请求处理，因为线程上下文切换，这样也会增长响应时间。

非 I/O 阻塞的应用程序将被 CPU 限制，由于它们没有线程等待时间，当请求获得处理的时候。

I/O 限制的应用程序

肯定 I/O 限制应用程序的线程池的大小是复杂的多，并依赖于下游系统的响应时间，由于一个线程会被阻塞直到其余系统响应了。咱们将不得不增长线程的数量,以便更好地利用 CPU，正如在 Reactor Pattern Part 1 : Applications with Blocking I/O 中的讨论。

利特尔法则

利特尔法则被用于非技术领域，好比银行须要计算出处理进入银行的客户所须要的出纳台的数量。

Little’s law

The long-term average number of customers in a stable system L is equal to the long-term 
average effective arrival rate, λ, multiplied by the average time a customer spends 
in the system, W; or expressed algebraically: 
L = λW.

利特尔法则应用于 Web 应用程序。

在一个系统中的平均线程数量等于平均的 web 请求到达率（每秒的 web 请求数），乘以平均响应时间（ResponseTime）。

线程 = 线程数
每秒 web 请求数 = 在 1s 内能被处理的 web 请求数
响应时间 = 处理一个 web 请求所花费的时间

线程 = (每秒 web 请求数) X 响应时间

当以上的方程式提供了须要的线程数来处理传入的请求，它没有提供线程 CPU 利用率的信息。好比，多少个线程应该被分配在给定系统的 X CPU。

测试肯定线程池大小

为了找出吞吐量和响应时间之间最佳平衡的线程池大小。每一个 CPU 最小线程启动开始（Threads Pool Size = No of CPUs），应用程序线程池大小直接与下游系统的平均响应时间成正比，直到 CPU 使用率爆了，或是响应时间降级。

下面的图说明了多少个请求数，CPU 和链接响应时间指标。

CPU Vs 请求数图表显示了增长 Web 应用程序负载的时候，CPU 的利用率。

响应时间 Vs 请求数图表显示了因为增长 Web 应用程序的负载，对响应时间的影响。

绿点表示最佳吞吐量和响应时间。

线程池大小 = CPU 数量

以上图表描述了阻塞 I/O 限制应用程序，当线程数等于 CPU 数时。应用程序线程被阻塞等待下游系统响应。由于线程被阻塞，响应时间随着请求进入队列增长。即便 CPU 利用率很是低，随着全部的请求被阻塞，应用程序开始拒绝请求。

大线程池

以上图表描述了当大量的线程在 Web 应用程序中被建立时，阻塞 I/O 限制了应用程序。因为大量的线程，线程切换将很是频繁。应用程序的 CPU 使用率会爆满，即便吞吐量没有增长，因为没必要要的线程上下文切换。由于上下文切换形成的请求被中断，响应时间降级。

最佳线程池大小

以上图表描述了当最佳线程池大小在 Web 应用程序中被建立的时，阻塞 I/O 限制了应用程序。CPU 获得有效使用，并由良好的吞吐量和更少的线程上下文切换。咱们注意到响应时间是适合因为请求被高效率的处理（不多的中断）。

线程池隔离

在大部分 Web 应用程序中，一些类型的 web 请求相对于其余类型的 web 请求须要更长的时间来处理。最慢的请求将夯住全部的请求，并下降整个应用程序的性能。

两种方法来处理这个问题：

• 有单独的系统来处理缓慢的Web请求
• 在同一应用程序中分配给慢的 web 请求一个单独的线程池

肯定一个阻塞 I/O Web 应用程序的最佳线程池大小是一个很是困难的任务。一般经过进行一些性能运行完成。有几个线程池在 Web 应用程序中会更加复杂化肯定最佳线程池大小的过程。