多线程客户端网络应用程序的性能

Question

我已经实现了将请求发送到服务器的客户端应用程序。它的工作方式可以非常简单地描述。我指定了多个线程。每个线程重复向服务器发送请求，并等待答案。

对于不同数量的线程，我已经绘制了客户端的总吞吐量。虚拟客户端的数量并不重要，我对图表最右侧的最大饱和性能很感兴趣。

我很惊讶，因为我没想到性能会随线程数而扩展。实际上，由于客户端与服务器之间的通信延迟为1毫秒，并且客户端在8核计算机上运行，因此大多数处理器时间都用于阻塞Java中的I / O（阻塞套接字）。

我一直在寻找在线解决方案，Quora上的答案似乎暗示可以将阻塞I / O的等待时间安排用于其他任务。是真的，特别是对于Java阻塞套接字吗？在那种情况下，为什么我不随线程数进行线性缩放？

如果这很重要，我将在云中运行此应用程序。另外，这是一个较大的应用程序的一部分，但是我已经将此组件确定为整个设置的瓶颈。

Answer 1

  

我已经在网上寻找解决方案，有关Quora的答案似乎   表示可以安排使用阻塞I / O的等待时间   用于其他任务。是真的，特别是对于Java阻塞套接字吗？

常规Java线程一对一映射到OS级线程。它们是等效的。是的，Java和实际上其他所有语言都是如此。除非它使用Green Threads或非阻塞IO。

  

在那种情况下，为什么我不得到与   线程？

从CPU的角度考虑您在做什么。 CPU执行昂贵的上下文切换，并允许某些线程运行。该线程在很短的时间内使用CPU来准备网络调用，然后阻塞很长时间（对于工作在3GHz的CPU来说，毫秒数是很大的）。

因此，在需要另一个上下文切换之前，每个线程仅执行少量工作。这意味着大量的CPU时间浪费在上下文切换上，而不是在做有用的工作。

将其与正在执行CPU-bound任务的线程进行对比。上下文切换花费相同的时间。但是，当允许运行CPU绑定的任务时，它可以设法长时间使用CPU，相比之下，上下文切换的成本更低。这样可以提高总体CPU利用率。

因此，一方面，您在每个新线程中看到的速率更高，因为您实际上是在执行更多的并发I / O操作。另一方面，每个新线程都会增加成本。因此，每个附加线程的边际收益每次都较小。如果您继续添加线程，则有时甚至会达到每个新线程使用率下降的地步。