弹簧反应在高负载下性能不佳

Question

我有一个默认使用 netty 的 spring boot webflux 应用程序。 我们的业务要求之一是请求应在 2 秒内超时。

当向应用发送的请求很少时，一切都很好，但是当请求负载增加时（例如 Jmeter 每秒超过 40 或 50 个并发），有时它们都会超时，因为每个请求都比 2-第二个阈值。

我花了很长时间在网上阅读内容并研究可能导致此问题的原因，但没有成功。当请求同时发送时，大多数最终会花费很长时间，而有问题的部分是向其他微服务发出外部 HTTP 请求的地方。我所有的测试都是本地的，我已经测试了微服务，它们看起来足够快，可以处理大负载，所以微服务本身不是问题。

我知道 netty 使用事件循环并且不会为每个请求创建一个线程。 我相信可能有同步任务阻塞了这几个网络线程。出于这个原因，我进行了大量重构，并在 Mono 反应链中使用了“.publishOn(Schedulers.boundedElastic())”或“.subscribeOn(Schedulers.boundedElastic())”。重构后大部分操作似乎都在弹性线程上运行，而不是“reactor-http-nio-x”（根据日志），但这样做并没有解决主要问题，问题仍然存在。

如果有人能指导我做我应该做的事情，那将是一个巨大的帮助。在这一点上，我没有更多的改进可做，并且认为我可能一直以错误的方式看待这个问题并且我的方法并不正确。

我没有附加任何代码，因为应用程序很大，我仍然不知道实际问题出在哪里。

Answer 1

我也遇到了同样的问题。我没有找到这个问题的根本原因，但是当我从 WebClient 切换到 RestTemplate 每个客户端（外部服务）使用专用线程池时，问题就解决了。我已经运行了一个 blockhound 来查找我是否在流中的某个地方阻塞，但它没有找到任何东西。我还尝试通过增加 NIO 工作线程池的数量（默认情况下它等于核心数）来部署我的应用程序并且有一些改进，但毕竟RestTemplate 产生了最佳性能。所以我还在 Webflux 堆栈上，但我不再使用 WebClient 并且在高负载下的性能很好。