概要

本文中，作者針對簡單的線程池和簡單的線程池（二）介紹的兩個線程池分別進行了並發測試，並基於收集的測試數據，對結果進行了分析。

目的

本測試是為了確認非阻塞式線程池與阻塞式線程池的生存性，以及兩者在吞吐量上的差異，為改進線程池提供數據支撐。

【注】這裡的差異以非阻塞式的吞吐量為基準計算得出的，即 (阻塞式吞吐量 – 非阻塞式吞吐量) ÷ 非阻塞式吞吐量 的百分比。類似並發、壓力之類的測試依賴於測試環境，因此筆者認為兩者在量級上的差異比絕對數據更有意義。

環境

考慮到兩個線程池的簡單程度，為易於顯示兩者之間的差異，筆者選擇了硬件配置偏低的測試環境，

硬件配置：Raspberry Pi 3 Model B
- Quad Core 1.2GHz 64bit
- 1G RAM
- 16G MicroSD
- 100 Base Ethernet
軟件配置：Raspbian Stretch
- g++ (Raspbian 6.3.0-18+rpi1+deb9u1) 6.3.0 20170516

用例

針對兩個線程池，測試過程模擬出 10 個用戶（線程）向線程池提交任務，分別實施如下 15 個測試用例，

編號	提交周期（分鐘）	思考時間（毫秒）
1	0.5	0
2	0.5	0 ~ 8 隨機
3	0.5	0 ~ 32 隨機
4	0.5	0 ~ 128 隨機
5	0.5	0 ~ 1024 隨機
6	1	0
7	1	0 ~ 8 隨機
8	1	0 ~ 32 隨機
9	1	0 ~ 128 隨機
10	1	0 ~ 1024 隨機
11	3	0
12	3	0 ~ 8 隨機
13	3	0 ~ 32 隨機
14	3	0 ~ 128 隨機
15	3	0 ~ 1024 隨機

收集如下測試數據，

提交的任務總數 (A)：在提交周期內，所有用戶提交的任務總數；
剩餘的任務總數 (B)：用戶結束提交時，線程池中剩餘的任務總數；
總時長 (C)：從提交任務開始到處理完所有任務之間的總時間，精確到千分之一秒。

得出 3 個吞吐量指標（任務數 ÷ 秒），

從開始提交任務到結束提交任務期間的吞吐量（1）：（A – B）÷（並發周期 × 60）；
從結束提交任務開始到處理完所有任務期間的吞吐量（2）： B ÷（總時長 – 並發周期 × 60）；
從開始提交任務到到處理完所有任務期間的吞吐量（3）： A ÷ 總時長。

如果把線程池接受任務的過程稱為「吞」，線程池分派任務的過程稱為「吐」，則根據前述吞吐量 1 ~ 3 的定義可以看出，吞吐量1 代表的是線程池在有用戶提交任務的時間段內的「吞」 + 「吐」的絕對能力；吞吐量2 代表的是線程池在無用戶提交任務的時間段內的「吐」的絕對能力；吞吐量3 代表的是線程池在有提交任務 + 沒提交任務的時間段內的」吞「 + 」吐「的整體能力。

每個測試用例執行 10 次，執行結果的平均值作為某指標的平均吞吐量。為了降低 I/O 對並發能力的影響，程序中任務輸出到 stdout 的內容都被重定向到 /dev/null，僅將 stderr 的內容輸出到終端。

測試用例執行文件：

非阻塞式： lockwise_test.cpp
阻塞式： blocking_test.cpp

測試

根據測試用例的要求，修改測試用例文件中的參數，
- 提交周期：修改 PERIOD 的初始值為 0.5，1 或 3；
- 思考時間：在用戶線程的初始函數中，放開或注釋以下內容，
  - std::this_thread::yield()，則思考時間為 0；
  - std::this_thread::sleep_for(milliseconds(rand()%RAND_LIMIT))，則思考時間為 0 ~ RAND_LIMIT 毫秒隨機（須同時修改 RAND_LIMIT 的初始值為 8，32，128 或 1024）。
編譯測試用例執行文件
- 非阻塞式： g++ -std=c++11 -lpthread lockwise_test.cpp
- 阻塞式： g++ -std=c++11 -lpthread blocking_test.cpp
執行
- ./a.out 1>/dev/null