如何衡量虚拟线程的效益？

Question

我将 Java 17 应用程序迁移到 Java 21 并为该应用程序启用了虚拟线程。

微服务详细信息：

• 容器上每秒 20 个请求。
• 此服务已启用扩展。每当平均 CPU 达到 30% 时，就会启动新容器。
• 通常有 50 个容器正在为此服务运行。
• 在没有虚拟线程的情况下，过去一个容器平均每分钟运行 2.5k 个平台线程。
• 我们在此服务上使用 GRPC 服务器。
• 请求详情：
  • 一个请求在平台线程上，一般使用6-7个并行平台线程从不同的数据源（I/O）获取数据。
  • 我们已经使用ExecutorService将后面的6-7个平台线程转换为虚拟线程。
  • 我们无法将用户请求移动到虚拟线程，因为 grcp 服务器不支持它。

当我们上线时，我可以看到早期系统平均有 2.5k 活动平台线程。现在已经减少到 200。但除此之外我没有观察到任何其他好处。

我所想，我会观察

• 增加每个容器的吞吐量。
• 使用的容器数量应该减少，因为现在由于活跃的平台线程较少，上下文切换更少。

除了减少平台线程数量之外，我没有看到任何好处。

我缺少什么？ 我还应该检查哪些其他参数会显示出改进？

Answer 1

最后，你认为什么是（显着）改进取决于你。如果某件事对你很重要，你应该衡量它。

例如，如果平台线程使用大量内存，您可能使用虚拟线程需要更少的内存。鉴于此，您可能想要测量在应用程序中使用的内存量但是，如果您使用虚拟线程同时处理更多请求（这可能需要更长的时间，因为系统的某些其他部分受到限制） ，内存量也可能会增加，因为更多的请求需要更多的内存。

这给我们带来了另一个可以衡量的指标：您同时服务了多少个请求（有或没有虚拟线程）？也许您可以使用虚拟线程同时处理更多请求。您可能想要测量请求所需的平均时间以及并行处理的请求数量。

您提到您希望在切换虚拟线程时提高吞吐量，但没有看到这一点。也许系统的另一个组件正在限制吞吐量。例如，如果您限制可用的 grpc/用户线程数量（或者如果您限制同时服务的请求数量），您将不会获得更高的吞吐量。您以前限制并发请求的方法对于您以前的方法来说可能是合理的，但它们会阻止您通过使用虚拟线程来增加吞吐量。由于您现在使用的平台线程总体较少，因此您可以增加用于处理用户/grpc 请求的平台线程数量（或使并发限制不那么严格）。 如果您期望更好的吞吐量，您应该调查实际限制吞吐量的因素（虚拟线程和平台线程）。

虚拟线程可以提高CPU利用率。但如果您的 CPU 利用率已经最大化，那么这对您没有多大帮助。如果平台线程的 CPU 限制达到 30%，那么虚拟线程可能仍会达到该限制。

除此之外，你还可以尝试其他的事情。
例如，您使用

ThreadFactory

为虚拟线程命名。如果您不需要这些名称，您可以跳过此步骤，这可能会导致使用更少的内存。
另一件值得尝试的事情是更新 grpc 服务器，特别是如果您受到 grpc 服务器正在使用的平台线程的限制。也许有支持虚拟线程的新版本可用？