想让性能测试更高效？“性能等式”了解一下！

lsekfe

　摘要：
　　在测试性能时，我们可以尝试编写一个“性能等式”，以便检查影响性能的每个因素。但是，就算逐一检查方程式里的每一项也并不总是能看清整体情况。有些影响性能的因素很容易被忽略。测试更多的是发现系统的行为，而不是对一些期望行为的样本进行验证。
　　许多团队为了查看系统是否能够满足业务需求，会搭建一套基于服务器和网络基础设施的“测试平台”，开发一些模拟用户请求的脚本，并运行这些脚本来测试应用程序。为了确保系统有额外的容量，他们会将事务数增加一倍。
　　但这种方法似乎只是有时起作用，这意味着它在其他时候失败了。而解释它为什么成功或失败也同样是件困难的事。
　　让我们先仔细看看构成“性能等式”的部分：

这里：
　　·Env 表示测试环境(网络、交换机、负载均衡器、服务器、数据库和平台软件)。
　　·WL 表示模拟用户行为的负载脚本。
　　·Code 表示应用程序代码，包括程序内部组件和第三方库。
　　·X 是一组性能特征，比如响应时间、吞吐量等。

　　环境
　　测试环境中的硬件和软件对应用程序的性能有多方面的影响。如果复制生产环境在经济上不允许的话，那么最好的选择是使用最接近生产环境的、可用的环境进行性能测试。通常，这可能是用户验收测试环境或生产前环境。典型的“挑战叉”是，使用比实际生产环境弱的测试环境可能会导致许多不真实的错误，而使用比生产环境强大的测试环境可能会掩盖真正的性能问题。
　　尽管在明显不同的硬件上进行测试的风险是显而易见的，但有些差异可能就不那么明显了。像服务器设置、内存分配和进程优先级，这些都是需要优先考虑的。应用程序的设置也可能会导致性能变化。比如，调试模式或日志记录的级别都有可能会显著改变文件操作的频率和数量。数据库结构和内容的复杂性也可能会对搜索和报告等功能产生显著的性能影响。要避免此风险，我们可以使用生产数据库的屏蔽副本。
　　而且可能需要几轮测试我们才能发现和纠正那些隐藏在环境部分的、影响性能的因素。

　　负载
　　负载模型通常基于服务级协议和业务需求。一些常见的示例包括事务数、并发用户数和响应时间。典型的需求可能如下所示：
　　允许并发数占2500个总用户基数的10%。
　　支持每小时执行2500次的交易量。
　　页面加载时间不应超过5 -10秒。
　　该系统应保持8小时内无操作。
　　这样的需求看起来非常简单，因此它们可能被用作工作负载模型。例如，根据上面给出的需求，您可能需要模拟250个并发用户每小时执行10个事务，每次8个小时。同时，还要测试页面加载时间。是的，为了测试额外的容量，我们可以每小时做20个事务，或者每三分钟做一次。
　　对这个简单直白的模型，我们有没有漏掉什么东西？
　　为了获得另一个视角，让我们将应用程序流量比作道路流量。一段100码长的路可以同时被10辆车占用。但是，当只有几辆车时，或者当他们一辆接一辆地行驶时，我们注意到行驶速度是不一样的。还要注意的是，在任何给定的路段上，同时并行的可能只有车道数那么多的车辆。如果车道数变了，车道数最少那一段，即能同时并行车辆数最少的路段，将极大地影响车辆行驶速度。
　　你可能知道这是怎么回事。在一段时间内平均分配事务的数量时，考虑到了用户的并发性，但没有考虑事务的并发性。虽然人们可能会争辩说，250个用户不太可能同时按下“提交”按钮，但是有10个用户这么做的可能性有多大呢？甚至是3个？这是我们最有可能遇到瓶颈的地方。
　　那么并发用户的总数呢？大多数负载测试工具和服务都有一个基于虚拟用户数量的定价模型，而且许多公司没有为250个虚拟用户颁发许可证。一个典型的解决方法是将脚本的速度提高一倍或三倍，以弥补事务的数量。虽然它在数学上是正确的，但是这种方法没有考虑到用户会话的数量对软件系统有非线性的影响。每个用户会话都需要分配资源(分配到应用程序的内存、服务器和数据库)，并且资源管理本身也有性能压力。因此，以三倍的速度运行脚本并不能真正弥补同等数量的用户行为。

　　代码
　　在我们的性能方程中，如果我们假设代码部分是唯一的变量，那么任何性能变化都应该意味着是由于最近的代码更改引起的。
　　一些代码更改可能确实会对性能产生巨大影响。但是，通常情况下，在性能问题变得明显之前，这里和那里的隐藏的小变化会累积一段时间。除非您有关于每个构建的性能基准的趋势图，否则很难注意到任何缓慢的下降。尽管测试可能会显示性能下降，但解决问题的困难之处在于缺乏单一的根本原因。
　　恒定工作负荷模型的目的是建立跟踪基准。它们以相同的加载方式执行相同的脚本。但这也意味着以同样的方式行使相同的应用程序功能。实际用户在使用中会执行各种操作。除了事务预订功能之外，它们还可以搜索、编辑、删除数据和运行报表。所有这些功能可能不会使负载增加，但是如果用户并行操作的话会对性能有实质的影响。
　　在相同的功能中也有新部署的特性，例如账户查找、编辑购物车等等。如果脚本以相同的方式提交事务，它们不会处理新增的那部分功能。

　　解X
　　所有的测试都是一种混合的活动：学习、建模、实验和调查。测试更多的是发现系统的行为，而不是对一些期望行为的样本进行验证。负载和性能测试也不例外。只有经过反复的尝试和错误，我们才能了解系统并开发有用的工作负载模型。
　　在你的性能方程中寻找隐藏的那部分吧——特别是当它看起来很容易解决的时候。