设计库性能比较测试

Question

我正准备对各种货架产品进行一系列性能比较。

我需要做什么才能在测试中显示可信度？我如何设计我的基准测试，使它们是可敬的？

对于测试的实际设计，我也很感兴趣。在不影响测试的情况下加载数据的方法(海森伯格测不准原理)，或者监控数据的方法……等

Answer 1

在不知道您正在尝试评估的是哪种“现成”产品的情况下，回答这个问题有点棘手。您是否在寻找UI响应性、吞吐量(例如，电子邮件、事务/秒)、启动时间等-所有这些都有不同的标准来衡量您应该跟踪什么，以及不同的测试或评估工具。但要回答你的一些一般性问题：

1. 的可信度-这一点很重要。试着确保你正在测量的任何东西都有很小的运行差异。利用多次运行同一场景的技术，去除异常值(即最低和最高)，并评估您的平均/最大/最小/中值。如果你正在做某种吞吐量测试，考虑让它长时间运行，这样你就有了一个很好的样本集。例如，如果您正在查看Microsoft Exchange之类的东西，因此正在使用它们的性能计数器，请尝试确保您正在频繁地进行采样(每秒一次或每隔几秒)，并让测试运行20分钟左右。同样，去掉前几分钟和最后几分钟，以消除任何启动/关闭noise.
2. Heisenburg的棘手问题。在大多数现代系统中，根据您正在测量的应用程序/度量，您可以通过聪明地了解您正在测量什么/如何测量来最小化这种影响。有时(就像在Exchange示例中一样)，您将看到接近0的影响。尽量使用侵入性最小的工具。例如，如果您正在测量启动时间，请考虑使用xperfinfo并利用内核中内置的事件。如果您使用的是perfmon，请不要使用您不关心的无关计数器来淹没系统。如果你正在做一些外部的长时间运行测试，降低你的采样间隔。

还要尝试消除任何环境可变性的来源或可能的噪声源。如果你正在做一些网络密集型的事情，考虑隔离网络。尝试禁用任何您不关心的服务或应用程序。限制任何类型的磁盘IO、内存密集型操作等。如果磁盘IO可能会在CPU受限的情况下引入噪音，请考虑使用SSD。

在设计测试时，请牢记可重复性。如果您正在进行某种类型的微基准测试(例如，perf单元测试)，那么让您的基础架构支持完全相同地运行n次相同的操作。如果你在驱动UI，尽量不要在物理上驱动鼠标，而是使用底层的可访问层(MSAA、UIAutomation等)以编程的方式直接点击控件。

再说一次，这只是一般性的建议。如果你有更多的细节，我可以尝试跟进更多相关的指导。

享受吧！

Answer 2

你的问题很有趣，但有点含糊，因为如果不知道要测试什么，就不容易给你一些线索。

您可以从许多不同的角度测试性能，然后，根据库的使用或目标，您应该尝试一种或另一种方法；我将尝试列举一些您可能需要考虑的测量事项：

• Multithreading:如果库使用它，或者您的软件将在多线程上下文中使用库，那么您可能必须使用许多不同的处理器和多处理器配置来测试它，以查看它的reacts.
• Startup时间:它的重要性取决于您使用库的强度以及使用它构建的产品的性质(客户端、服务器…)。
• Response time:为了避免第一次执行，请尝试在第一次调用之后多次执行相同的调用，并求平均值。使用System.Diagnostics.StopWatch可能对此非常有用。
• 内存消耗:分析增长，注意指数增长;)。更进一步，测量正在创建的对象和disposed.
• Responsiveness:的数量您不仅应该测量原始性能，用户对产品速度的感受这一点非常重要too.
• Network:如果库使用网络上的资源，您可能必须使用不同的带宽和延迟配置对其进行测试，有软件可以模拟这些situations.
• Data:尝试创建许多不同的测试数据包，尝试涵盖例如:一大堆原始数据，然后是由许多较小的区块组成的大集合，具有小数据片段的长时间迭代，…

工具：

• System.Diagnostics.Stopwatch：基准测试的必备方法calls
• Performance counters：只要有，它们对了解内部发生的事情非常有用，允许您在不影响其performance.
• Profilers:的情况下监控软件市场上有一些良好的内存和性能分析器，但正如您所说，它们总是会影响度量。它们有助于查找软件中的瓶颈，但我不认为您可以将它们用于比较测试。

Answer 3

你为什么要关心表演呢？在这两种情况下，将消息写入存储日志的位置所需的时间将比其他任何情况都要慢得多。

如果您真的在执行匹配日志记录，那么您可能需要对日志文件进行索引，以便能够找到所需的日志条目，此时您不是在执行标准日志记录。