在寫測試用例時，順手做了一個TASK模型的壓力測試。發現TASK模型的性能極其低下！
數據處理邏輯：
1：主程序不停發送數據修改命令
2：數據管理器，接收命令，緩存命令。
3：後臺線程分批次處理，一次處理一批命令，按照命令內容讀寫數據，修改文件。
4：完成後， 調用Task.Start函數，讓等候該批次任務的命令執行後續操作。
5：完成後續操作，完成處理流程。
問題：
在使用接口避開Socket操作後，只剩下對文件系統的操作時，系統的效率極其低下。CPU使用率不超過1%，磁盤使用率不超過1%（最大0.9M/S）。硬件性能完全沒有發揮出來！
進一步分下，發現主要是命令排隊存在問題：
大量的操作是一個命令執行一次，僅少數幾次，會有多個命令同時執行。並沒有在緩衝區緩存大量數據，讓文件操作效率更高。
原因分析：
從等待任務的各種跡象看，導致緩衝邏輯失效的根本原因是 TASK的等待操作。Task.ContinueWith函數，會導致任務等待，這種等待不是線程阻塞，但當任務隊列達到配置的最大值後，系統會阻塞新建Task。阻止新建任務，可以從源頭上降低系統吞吐能力，保證系統穩定性。
哎~。微軟的技術都是看起來好，較真起來就沒用了！