【发布时间】：2010-02-26 10:57:59
【问题描述】：
在过去（单线程）时代，我们指示我们的测试团队始终报告 CPU 时间，而不是应用程序的实时时间。这样一来，如果他们说在版本 1 中一个操作需要 5 CPU 秒，而在版本 2 中需要 10 CPU 秒，那么我们就有问题了。
现在，随着越来越多的多线程，这似乎不再有意义。可能是应用程序的版本 1 需要 5 CPU 秒，版本 2 需要 10 CPU 秒，但是如果版本 1 是单线程的，那么版本 2 仍然更快，版本 2 使用 4 个线程（每个线程消耗 2.5 CPU 秒） .
另一方面，使用实时来比较性能也不可靠，因为它会受到许多其他因素的影响（其他正在运行的应用程序、网络拥塞、非常繁忙的数据库服务器、碎片磁盘……） .
您认为“计算”性能的最佳方式是什么？ 希望这不是直觉，因为这不是客观的“价值”，可能会导致开发团队和测试团队之间发生冲突。
【问题讨论】：
-
你不能在没有加载无关程序的系统中测量挂钟时间吗？
-
@Mike，对于长时间运行的操作，是的。但有时，如果某些操作的时间从 1 秒增加到 1.2 秒，测试团队也会报告性能下降。这很难用挂钟来衡量（但在那些情况下，我也对实际的性能问题表示怀疑）。
-
我相信您明白我的意思不是挂在墙上的物理塑料电子钟，而是指一天中的结束时间减去一天中的开始时间。这与某些分析器所做的尝试测量不同于 I/O 时间的进程内 CPU 时间的方法形成对比。 IMO 后者可能会满足一些好奇心，但对定位问题帮助不大。
标签： testing performance