并行、延迟与吞吐量

原文地址：https://chanjarster.github.io...

在实践中咱们能够将任务拆分红多个子任务并行执行来提升程序的性能。

“性能”这个词过于含糊，更准确的说应该是：延迟（latency）和吞吐量（throughput）。本文举几个简单的例子来解释在固定线程池大小的状况下，不一样的并行程度与延迟和吞吐量的关系。

场景

假设咱们如今有一个task，其执行时长须要2秒。这个task能够被无限拆分，而且执行时长等比例缩减,好比拆分红2个task，那么执行时长变成1秒。同时咱们有一个容量为6的线程池，这意味着同一时间范围内最多只能有6个线程工做，同时每一个线程能够独占一个CPU核心。

而后给出不一样尺寸的工做集——一个尺寸为4的工做集表明意味着有4个task待执行——来观察当task被各类拆分时的吞吐量和延迟：

• task不被拆分时
• task被拆分红2个sub-task的状况
• task被拆分红4个sub-task的状况
• task被拆分红8个sub-task的状况

先来看看task不被拆分时的执行状况：

图中例举的当工做集尺寸=10时，每一个task的执行时间状况。每一条线都是一个task，橘黄色部分是真正的执行时间，蓝色虚线是等待所花费的时间。这些task被同时提交到线程池中，因此起点相同。由于线程池大小为6，所以前6个task没有等待时间，从第7个task则必须等前面的task执行结束后才能开始执行，它须要等待2秒（单个task的执行时长为2秒）。

下面是task被拆分红2个subtask的执行状况：

能够看到task被拆分红2个subtask，每一个task所须要的线程也变成了2，总的时间减半变成1秒。和前一个图同样当线程池用满的时候，新的task/subtask必须等待。

下面是task被拆分红4个subtask的执行状况：

下面是task被拆分红6个subtask的执行状况（注意时间单位不一样了），图里的1根线条表明2个subtask：

这个是task被拆分红8个subtask的执行状况（注意时间单位不一样了），图里的1根线条表明2个subtask：

吞吐量对比

吞吐量的计算公式：吞吐量 = task数量 / 最慢的task所花费的时间。

下面是吞吐量对比图：

图中吞吐量线条的锯齿不用在乎，由于这和是否用足了线程池中的线程有关。拿不拆分task举例，当工做集=1时，吞吐量 = 1 / 2 = 0.5 tasks/sec，当工做集=6时 吞吐量 = 6 / 2 = 3 tasks/sec。当工做集=7时 吞吐量 = 7 / 4 = 1.75 tasks/sec，降低了，这是由于有5个线程空闲着没有工做，第7个task拖了后腿。因此咱们只须要看吞吐量峰值就好了。并且不出意外能够看到，当subtask数量为6是，吞吐量稳定在3 tasks/sec，这是由于老是会用足线程池中的线程。

能够看到不管是task如何拆分，吞吐量的峰值都是3 task/sec。在如何估算吞吐量以及线程池大小提到计算吞吐量的公式：

在咱们这个场景中，Tw=0，因此公式就变成了 C / Tc，咱们的C=6，而Tc=2s，因此吞吐量就是3 tasks/sec。

同时能够看到，当6个CPU用满的状况下，不管任务如何作并行化处理，其吞吐量峰值维持不变。

固然你也不可能经过扩大线程池来提升吞吐量，由于CPU的数量是固定的。

延迟对比

下面是延迟平均数、延迟中位数、延迟95%位数、延迟99%位数、延迟100%位数（最大延迟数）的对比图。

不出所料，当并行程度越高的时候延迟就越低，可是要注意的是，并行程度的增高所带来的延迟下降的边际效益是递减的。

当subtask > 6时

那么当subtask数量 > 6 时会发生什么？下面是subtask分别为八、10时候的吞吐量、延迟数据。

能够看到吞吐量峰值保持不变，依然是3 tasks/sec。延迟比subtask=6时略有增长。上图只是理论值，实际状况中考虑到线程频繁调度等开销，结果会更糟。

数据excel能够在这里下载。