並行、延遲與吞吐量

原文地址：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能夠在這裏下載。