在写测试用例时,顺手做了一个TASK模型的压力测试。发现TASK模型的性能极其低下!
数据处理逻辑:
1:主程序不停发送数据修改命令
2:数据管理器,接收命令,缓存命令。
3:后台线程分批次处理,一次处理一批命令,按照命令内容读写数据,修改文件。
4:完成后, 调用Task.Start函数,让等候该批次任务的命令执行后续操作。
5:完成后续操作,完成处理流程。
问题:
在使用接口避开Socket操作后,只剩下对文件系统的操作时,系统的效率极其低下。CPU使用率不超过1%,磁盘使用率不超过1%(最大0.9M/S)。硬件性能完全没有发挥出来!
进一步分下,发现主要是命令排队存在问题:
大量的操作是一个命令执行一次,仅少数几次,会有多个命令同时执行。并没有在缓冲区缓存大量数据,让文件操作效率更高。
原因分析:
从等待任务的各种迹象看,导致缓冲逻辑失效的根本原因是 TASK的等待操作。Task.ContinueWith函数,会导致任务等待,这种等待不是线程阻塞,但当任务队列达到配置的最大值后,系统会阻塞新建Task。阻止新建任务,可以从源头上降低系统吞吐能力,保证系统稳定性。
对于该问题的处理办法就是: 避免使用ContinueWith函数,该函数会导致阻塞逻辑产生,和lock语句相同!
所有ContinueWith函数都已换成 await 关键字。 这种多线程的理解差异,对使用begin-end方式进行异步开发的老人而言,需要不少的时间来理解!