背景(如果不感兴趣,请跳到下面的问题)
我有一个模拟器,经历了三个阶段:
- 单线程启动(I/O正常)
- 多线程内存CPU密集型模拟阶段(I/O出现问题)
- 模拟后,单线程阶段完成(I/O正常)
这是什么鬼! 在标准测试中,CPU使用率从100%降至20%,总运行时间比正常情况下慢了约30倍(130秒对比4.2秒)。
当Callgrind
没有发现任何可疑的情况时,我开始想要回滚到上一个提交,以便丢失所有的错误修复。
失望的是,我走进服务器房间,并听到刺耳的金属声,后来证实是在/proc/PID/fd中写入Mysql sockets引起的!!! 这表明在第2阶段深层次的Mysql代码引起了问题。
所学到的教训
- 意外的I/O对实时应用程序可能会造成致命的影响
- 单元测试不够:我还需要基准测试
解决方法 我将引入线程本地存储IOSentinels,并在ReadAllowed()和WriteAllowed()上使用assert()来确保Stage 2线程永远不会进行任何IO。
问题
有人成功地使用googletest附加/编写基准测试框架吗?
遗憾的是,这次所有的googletest都通过了。如果我稍微离开一下,回来时没有注意到运行时间,那么这将是一个灾难性的提交,可能更难修复。
我希望 googletest 失败,如果运行时间比上一次运行时间长2或3倍:这个最后的部分很棘手,因为对于非常快速的运行,系统状态可能导致某些操作需要两倍的时间,但仍然是可接受的。但对于长时间的模拟运行/测试,我不希望运行时间有很大变化(>50%将会是不寻常的)。
我在这里开放建议,但希望有一个低维护的检查,能够与自动化测试一起使用,这样即使所有输出看起来都正常,如果系统突然变慢,也很容易发现。
EXPECT_LT( TEST_RUNTIME, 1000)
表示少于一千毫秒... - kfmfe04