如何测试应用程序吞吐量:保持真实吗

我们经常看到一个web应用程序的吞吐量。这是一种量化的请求/响应量的关系。每秒事务数或TPS是最常见的使用比例。性能测试计划通常包含特定的吞吐量目标。去/不方便决定推出一个新版本或建筑变化很大程度上依赖于一定的TPS web应用程序处理。管理希望“通过”邮票,但你的工作确保实现TPS确实是真实的,不是虚假的错觉。

我的建议是,“保持真实”通过生成工作负载,代表所有生产的真实特征。假装它会导致假阳性测试结果:一定TPS是“通过”邮票被授予,但条件是不现实的。

例如,您可以实现一个460 TPS的结果按主要轻量级事务,或通过运行低负载的虚拟用户提供很少或根本没有思考时间。在这些情况下,吞吐量将“高”,但工作量并不代表真正发生在生产。即使是远程。更糟的是,如果你“通过”性能测试使用这些不切实际的方法,你不知道如果部署将承受生产工作负载。如果应用程序摔倒。猜猜谁是热座位吗?这可能是一个意外的结果,所以要确保你的测试设置正确,并创建一个现实的工作负载。

从设计开始

我怎么完成?实际上测试的设计,负责决定现实的吞吐量是你产生。有几个关键因素来考虑。他们都是同等重要的,但潜在的哲学是(再次)“保持真实。“使用加载工具来模拟虚拟用户执行脚本是一个负载测试,但您还需要模仿准确的活动,条件,行为、使用等。每个脚本中执行负载测试包含简单的请求和更复杂的商业交易。当建立一个应用程序的测试,并不是所有的交易都是平等的。吞吐量受到一个事务的“重量”。

例如,轻量级事务可以简单地提供一个静态图像。在另一个例子,重量级的事务B可以执行业务事务那么复杂,涉及算法运行在数据库查询的结果。事务的响应时间会更快,并将在部署中使用更少的资源,因为它只是一个web服务器响应。相反,我们可以预计,事务B有更长的响应时间和使用更多的资源,包括数据库。当加载工具执行一个脚本,它等待响应事务在执行下一个事务。你可以看到事务的响应时间如何影响吞吐量。事务响应时间越快,越高的吞吐量。你可以很容易地操纵一个测试所以你必须真正模拟预期的生产活动创造条件。

虚拟用户应该反映真实用户

准确地模拟预期的生产活动首先必须确保每个虚拟用户代表每一个真正的用户。如果你期望的并发负载2500活跃用户使用您的web应用程序,那么您需要有一个坡道测试2500个虚拟用户。这非常重要,因为每个虚拟用户都有一个独特的足迹在会议后端服务器,内存使用,打开的套接字等。试图逃脱一个更高的吞吐量测试没有准确数量的虚拟用户将导致不精确的后端资源的使用。只有一个测试使用的真实数字用户会模仿正确的负载条件。

通常有不同“类型”的每个web应用程序的用户:顾客,买家,管理,等设置测试时,创建一个人口,事务混合物,代表了工作负载高峰在生产中使用。例如,50%的购物者,40%的买家,10%的管理。最准确的事务将由业务分析的日志评论或预期使用在生产。脚本执行的工具的负载生成器需要代表“真正”的用户配置文件。脚本需要遵循事务流:导航,决策,输入,计算等。这些交易需要使用动态数据是现实的。动态事务流包括不同产品的选择、连接请求,表单提交,甚至更复杂的提取响应数据用于后续请求。188金宝搏官网app注册动态脚本,模拟真实用户的多样化的活动。

包括思考时间

让这些机器人虚拟用户像人类,暂停/延迟需要纳入脚本。我们都需要思考,接受信息,过程,做出决定,输入形式,等等。这些“呼吸器”有助于精确的负载特征。这些停顿期间,服务器仍执行家务:关闭港口、垃圾收集、测量超时,彻底的会话,等等,所有这些资源。如果你点击部署和并发用户简单地打开吞吐量,负载特性是不现实的。

与今天的富Internet应用程序(ria),有一个要求,把复杂的行为纳入到脚本。表示异步更新的数据从服务器被推到浏览器,反之亦然,独立的页面刷新。“倾听”的工具需要更新和重新创建一个脚本,模拟活动。这是一个障碍性能测试还创建正确的负载特征的关键。通过使用轮询,这些丰富的行为影响吞吐量流和其他反应机制必须占。

连接速度问题

另一个需要考虑的因素是用户通过不同的网络连接到网络和移动应用程序的速度。连接速度会影响下载速度。下载,越慢越高响应时间。为你的用户的数量,选择真正代表最终用户的带宽(s)连接。例如,你可能与一个已知的测试局域网应用程序的带宽限制。或有一群来自另一个国家的用户。一定比例可能只访问一个web应用程序通过一个移动网络。

考虑到所有这些因素(用户配置文件,准确的用户数量,事务混合,动态数据,思考时间,带宽模拟、行为等)奠定了基础为创建现实的吞吐量。回顾你的脚本和确保你的测试真正代表预期的生产。设计了实际的测试后,您可以执行,妥善评估web应用程序是否可以达到吞吐量目标。

这篇文章最初发表在2012年和2021年7月被刷新。