multithreading - 如何确定Tomcat中的最佳线程数？

Question

如何确定Tomcat中maxSpare，minSpare和maxThreads，acceptCount等的最佳数量？是否有现有的最佳做法？

我确实知道这需要基于硬件(例如，每个内核)，并且只能作为针对特定硬件进行进一步性能测试和优化的基础。

Answer 1

“多少线程问题”是一个很大而又复杂的问题，不能凭简单的经验法则来解决。

考虑拥有多少个内核对于倾向于消耗大量CPU(例如数字运算等)的多线程应用程序很有用。对于Web应用程序，这种情况很少发生，通常不是由CPU而是由其他因素引起的。

一个常见的限制是您与其他外部系统(尤其是数据库)之间的滞后。每次请求到达时，它可能都会查询数据库多次，这意味着通过JDBC连接流式传输一些字节，然后等待这些字节到达数据库(即使它在localhost上也有很小的滞后)。 ，然后等待数据库考虑我们的请求，然后等待数据库对其进行处理(数据库本身将等待磁盘搜索到特定区域)等。

在所有这些时间中，线程处于空闲状态，因此另一个线程可以轻松地使用该CPU资源来执行有用的操作。看到40％到80％的时间用于等待数据库响应是很常见的。

连接的另一端也发生相同的情况。当您的线程将其输出写入浏览器时，CLIENT连接的速度可能会使您的线程保持空闲状态，以等待浏览器确认已接收到某个数据包。 (几年前，这是一个相当大的问题，最近的内核和JVM使用更大的缓冲区来防止线程以这种方式空闲，但是，Web应用程序服务器前的反向代理(甚至只是一个httpd)对于避免人们使用确实很有用。具有不良的Internet连接以充当DDOS攻击:))

考虑到这些因素，线程数通常应该比您拥有的内核多得多。即使在简单的双核或四核服务器上，也应至少配置几十个线程。

那么，什么限制了您可以配置的线程数呢？

首先，每个线程(用于)消耗大量资源。每个线程都有一个堆栈，该堆栈消耗RAM。而且，每个线程实际上都会在堆上分配内容以完成其​​工作，从而再次占用RAM，并且对于JVM/OS内核，线程之间的切换(上下文切换)非常繁重。

这使得很难“平稳”地运行具有数千个线程的服务器。

给出这张图片，可以使用多种技术(主要是:尝试，失败，调整，重试)来或多或少地确定您的应用将需要多少个线程:

1)尝试了解您的线程在哪里花费时间。有很多很好的工具，但是jvisualvm profiler可能是一个很好的工具，或者是一个跟踪方面，它可以产生摘要时序统计信息。他们花在等待外部事物上的时间越多，您可以产生更多的空闲线程来使用CPU。

2)确定您的RAM使用率。假设JVM将使用一定数量的内存(最显着的是permgen空间，通常高达一百兆字节，jvisualvm会再次告知)，而不管您使用了多少线程，请尝试先运行一个线程，然后运行十个线程，然后再运行一百，同时使用jmeter或其他工具强调应用程序，并查看堆使用率将如何增长。这可能构成一个硬性限制。

3)尝试确定目标。每个用户请求都需要一个线程来处理。如果每个“获取”的平均响应时间为200毫秒(最好不要考虑加载图像，CSS和其他静态资源)，则每个线程每秒可以处理4/5页。如果期望每个用户每3/4秒“单击”一次(取决于是浏览器游戏还是包含大量长文本的网站？)，那么一个线程将“服务20个并发用户”，无论其含义如何。如果在高峰时间在一分钟内有500位单用户访问您的网站，则您需要足够的线程来处理此问题。

4)碰撞测试上限。使用jmeter，在备用虚拟机上配置具有很多线程的服务器，并查看超过一定限制时响应时间将如何变差。在这里，底层操作系统的线程实现比硬件更重要，但是无论遇到什么情况，CPU都将花费更多的时间来尝试确定要运行哪个线程，而不是实际运行它，而这个数字并不是那么令人难以置信高的。

5)考虑线程将如何影响其他组件。每个线程可能会使用一个(或可能不止一个)与数据库的连接，数据库是否能够处理50/100/500并发连接？即使您使用的是Nosql服务器的分片群集，服务器场在这些计算机之间是否提供足够的带宽？与Web应用程序服务器在同一台计算机上还能运行什么？ Anache httpd？乌贼？数据库本身？像mongos或memcached这样的数据库本地缓存代理？

我已经看到生产中的系统只有4个线程+ 4个备用线程，因为该服务器完成的工作仅仅是调整镜像大小，因此这几乎是100％的CPU密集型工作，而其他服务器则在几乎相同的硬件上配置了数百个线程，导致Webapp对外部系统进行了许多SOAP调用，并花费了大部分时间等待答案。

一旦您确定了大约。最适合您的webapp的最小和最大线程，然后通常以这种方式配置它:

1)根据RAM的限制，其他外部资源和上下文切换实验，必须达到一个绝对最大值。因此，使用maxThreads将其限制为该数字的一半或3/4。

2)如果应用程序运行速度相当快(例如，它公开的REST Web服务通常发送响应的时间为几毫秒)，则可以配置较大的acceptCount，最多可以配置相同数量的maxThreads。如果您在Web应用程序服务器的前面有一个负载平衡器，请设置一个较小的acceptCount，对于负载平衡器来说，查看未接受的请求并切换到另一台服务器比让用户搁置已经很忙的服务器更好。

3)由于(仍然)启动线程被认为是繁重的操作，因此在高峰时段到来时，请使用minSpareThreads准备好几个线程。这又取决于您期望的负载类型。设置minSpareThreads，maxSpareThreads和maxThreads甚至是合理的，以便始终准备好准确数量的线程，永不回收，并且性能是可预测的。如果在专用计算机上运行tomcat，则可以提高minSpareThreads和maxSpareThreads，而不会占用其他进程的危险，否则请调低它们，因为线程是与大多数OS上其余进程共享的资源。