设计库性能比较测试

Question

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

我需要做些什么才能在测试中表现出可信度？如何设计我的基准测试以使它们受到尊重？

我也对测试的实际设计有任何建议。在不影响测试的情况下加载数据的方法（海森堡不确定性原理），或监控方法等等

Answer 1

如果不知道您想要评估什么样的“现成”产品，这有点难以回答。您是在寻找UI响应，吞吐量（例如电子邮件，事务/秒），启动时间等 - 所有这些都有不同的标准，您应该跟踪哪些措施以及用于测试或评估的不同工具。但要回答一些一般性问题：

1. 可信度 - 这很重要。尽量确保无论你测量的是什么都没有运行差异。利用相同场景的多次运行技术，摆脱异常值（即最低和最高），并评估你的平均值/最大值/最小值/中值。如果您正在进行某种吞吐量测试，请考虑使其长时间运行，以便您拥有良好的样本集。例如，如果您正在查看类似Microsoft Exchange的内容并因此使用其perf计数器，请尝试确保您经常采样（每秒或每几秒一次）并让测试运行20分钟左右。再次，切断前几分钟和最后几分钟，以消除任何启动/关闭噪音。

2. 海森堡 - 很棘手。在大多数现代系统中，根据您测量的应用/测量，您可以通过智能测量您的测量来最小化这种影响。有时候（比如在Exchange示例中），您会看到接近0的影响。尽量使用尽可能少的侵入性工具。例如，如果您正在测量启动时间，请考虑使用xperfinfo并利用内核中内置的事件。如果您正在使用perfmon，请不要使用您不关心的无关计数器来充斥系统。如果您正在进行一些极长的运行测试，请缩短采样间隔。

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

在设计测试时，请记住重复性。如果您进行某种微基准测试类型测试（例如，执行单元测试），那么让您的基础架构支持运行相同的操作n次完全相同。如果您正在驾驶UI，请尝试不要物理驱动鼠标，而是使用底层辅助功能层（MSAA，UIAutomation等）以编程方式直接命中控件。

同样，这只是一般建议。如果您有更多细节，那么我可以尝试跟进更多相关指导。

享受！

Answer 2

你的问题非常有趣，但有点模糊，因为不知道测试什么并不容易给你提供一些线索。

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

• 多线程：如果库使用 它或您的软件将使用 多线程上下文中的库 那么你可能需要测试它 许多不同的处理器和 多处理器配置来看 它是如何反应的。
• 启动时间：它 重要性取决于多么密集 你会使用图书馆吗？ 正在建造的产品的性质 用它（客户端，服务器......）。
• 响应时间：为此不要 第一次执行，尝试执行 之后多次同样的电话 第一个并做一个平均值。运用 System.Diagnostics.StopWatch可以 非常有用。
• 内存 消费：分析增长， 要小心指数的;）。去吧 进一步测量数量 正在创建和处置的对象。
• 响应能力：你不应该只是 测量原始性能，用户如何 感受到产品的速度 非常重要。
• 网络：如果 library使用网络上的资源 你可能需要测试它 不同的带宽和延迟 配置，有软件 模拟这些情况。
• 数据： 尝试创建许多不同的测试 数据包，试图掩盖，为 示例：大量原始数据， 然后是一个由许多小的组成的大集 块，一个很小的长迭代 数据，......

工具：

• System.Diagnostics.Stopwatch：对基准方法调用至关重要
• Performance counters：只要有可用，它们对于了解内部发生的情况非常有用，允许您监控软件而不影响其性能。
• Profilers：市场上有一些很好的内存和性能分析器，但正如你所说，它们总会影响测量。它们有助于找到软件中的瓶颈，但我认为您不能将它们用于比较测试。

Answer 3

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

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