【问题标题】:Performance Testing - How much data should I create性能测试 - 我应该创建多少数据
【发布时间】:2011-01-17 06:25:08
【问题描述】:

我是性能工程的新手,所以我有一个非常基本的问题。

我正在使用 SQL Server 后端的客户端-服务器系统中工作。该应用程序是一个巨大的税务相关应用程序,需要在峰值负载下测试性能。这意味着当我们运行与创建和提交纳税申报表相关的场景时,系统中应该有大约 1000 万份纳税申报表。然后还会有成比例的用户需要创建。

现在我在会议上听说我们需要创建 1000 万条记录来测试性能并运行具有 5000 个用户的场景,但我认为这是不可行的。

当谈到创建更小的数据集并推断性能规划时,我听到的一个非常常见的答案是我们需要 1000 万条记录,因为我们无法从更小的数据集中判断数据库或网络的行为方式。

那么如何在不创建峰值级别的数据或运行峰值数量的场景的情况下规划大型企业应用程序的容量和测试性能?

谢谢。

【问题讨论】:

    标签: sql-server performance


    【解决方案1】:

    现在我在会议上听说我们需要创建 1000 万条记录来测试性能并运行具有 5000 个用户的场景,但我认为这是不可行的。

    你为什么这么认为?

    当然,您可以(并且应该)使用有限数量的数据进行测试,但您也确实,确实需要使用实际负载进行测试,这意味着使用数量(和类型)的您将在生产中使用的数据。

    这只是一般规则的特例:对于系统或integration testing,需要在尽可能接近生产的场景中进行测试;理想情况下,您只需复制/克隆实时生产系统、数据、配置和所有内容,然后将其用于测试。这实际上就是我们所做的(如果我们在技术上可以并且客户同意)。我们只是运行一些 SQL 脚本来随机化测试数据集中的个人数据,从而避免隐私问题。

    总是会出现问题,因为生产数据与您测试的数据有所不同,这是防止(或至少限制)这些问题的唯一方法。

    我已经计划并实施了报告和导入,但它们总是在第一次接触真实数据时出现故障或行为不端,因为总会出现您未预料到的特殊情况或扩展问题。您希望这种破坏发生在开发过程中,而不是在生产过程中:-)。

    简而言之:

    咬紧牙关,(用“玩具数据”完成所有测试之后),获得一个真实的数据集进行测试。如果您没有硬件来处理这个问题,那么您就没有适合您的测试的硬件:-)。

    【讨论】:

    • 为此 +1。在某些应用程序中,使用少于 100 亿 条记录进行测试是没有用的。假测试只能得到假结果。
    • 非常感谢。我想我们将不得不尽可能接近负载。你的回答真的很有帮助。
    【解决方案2】:

    为了帮助生成数据,请查看 ruby​​ faker 和 perl data faker。在生成用于测试的大型数据集时,我很幸运。 redgate 的 SQL 生成器也不错。

    【讨论】:

    • 谢谢。我们正在研究这个工具。
    【解决方案3】:

    就个人而言,我会尽可能多地投入数据和流量。忘记你“认为你需要处理”的流量。看看你可以处理多少流量并从那里去。了解系统的限制比仅仅知道它可以处理 1000 万条记录更有价值。

    也许它确实处理了 1000 万,但在 1100 万时它会死得很惨。或者也许它写得很好,在它死之前会扩展到 1 亿。即使都通过了“千万考验”,两者还是有非常明显的区别

    【讨论】:

    • 不错的主意,但我相信使用“真实”数据进行测试通常比测试您的系统可以处理多少更重要。但这当然取决于预期用途。
    • @sleske,您应该使用真实数据进行测试。但不切实际的数量是相当有益的。
    • 是的,我们将尝试找到系统突破 1000 万以上的点。目前我们甚至可以达到我们的目标:)
    【解决方案4】:

    我会看看 Redgate 的 SQL Data Generator。它在生成具有代表性的数据方面做得很好。

    【讨论】:

      【解决方案5】:

      理想情况下,您的测试数据是各种真实的记录。但是对于第一个近似值,您可能只有一些独特的记录,并复制它们直到您获得所需的大小。然后用ApacheBench粗略估计一下流量。

      【讨论】:

      • 如果您完全复制记录,您并不能真正了解性能。例如,在现实生活中具有大部分唯一值的键效果很好,但对于大量重复值则效果不佳。
      【解决方案6】:

      看看“应用程序性能测试的艺术 / Ian Molyneaux,O'Reilly,2009 年”。

      【讨论】:

        猜你喜欢
        • 2012-10-15
        • 1970-01-01
        • 2012-11-06
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        相关资源
        最近更新 更多