java - http请求的线程池

Question

我有几个关于并发架构和性能的问题。

设置:

有一个 JavaFX GUI，用户可以在其中启动各种任务，这些任务本身就是线程任务 (new Thread(new CustomTask<?>).start();)。如果为数据库准备的插入语句中有大约 10k 个项目，这些任务会为大约 700k HTTP 请求执行一个循环并插入处理后的返回值。他们的进度显示在 GUI 中(ObservableList 项)。

问题:

这些任务需要很长时间，瓶颈似乎是等待 HTTP 响应时的延迟。 (DB 插入是在 10k 准备好的插入语句的批量关闭自动提交的情况下完成的)

目标:

通过在单独的任务/线程中处理请求来提高整体性能。

---

问题1:

在这里使用线程是否合理？我怎样才能以其他方式提高性能？

问题2:

如果线程是合理的，我该如何实现呢？ 我正在考虑拥有一个全局线程池或 ExecutorService请求任务排队的地方。当响应可用时，它将被写入同步列表。如果列表中有 10k+ 个对象，则执行批量插入。

问题3:

如何确定合适的线程池大小？如何区分线程？

Thread.activeCount() 返回 7(当前线程组) ManagementFactory.getThreadMXBean().getThreadCount() 返回 13(线程总数？) Runtime.getRuntime().availableProcessors() 返回 8

我读过一些关于多线程的评论，他们都说拥有比核心更多的线程并不一定会提高性能(没有“真正的”并发、时间片)。我不知道，但如果非要我猜的话，我会说数字 13 包含一些 GUI 线程。我似乎无法思考如何为 ThreadPoolSize 获取有用的数字。

---

我很感激任何关于如何改进我的应用程序的提示。

Answer 1

Q1

首先，不清楚您需要用什么来回复客户。您是否必须与数据库对话才能发回响应？

如果您不这样做，那就是 Pub/Sub 模式(即它的即发即忘)，那么消息队列或任何发布/订阅系统都是理想的，并且比使用普通 ExecutorService 的扩展性要好得多。一些例子是 AMQP , JMS, Redis Pub/Sub还有很多。

您可以通过对客户端的回复来执行发布/订阅，但这通常需要非阻塞客户端连接，例如 WebSockets、Comet，并且设置起来相当复杂。

Q2 and Q3

如果您的问题是您确实需要回复客户端，那么它遵循请求/回复模式，这是一个更难扩展的问题。

一些在 JVM 上做得很好的库是 Hystrix它遵循命令和舱壁模式，提供可配置和容错的请求/回复以及 request collapsing我相信这可以解决您的问题:“如果列表中有 10k+ 个对象，请执行批量插入。”

确定合适的池大小对于阻塞操作来说实际上是相当复杂的。对于非阻塞(即 cpu 绑定(bind)或在内存处理中)，它只是可用的处理器，但对于您来说情况并非如此，因为您连接到数据库并且可能使用阻塞 IO servlet 容器。

要为阻塞操作找出合适的池大小，您将使用 Hystrix 提供的开箱即用的指标和监控。您还应该了解您的下游依赖项。例如，如果您的数据库只能处理 200 个并发连接，您不希望与大于 200 的数据库对话的线程池。