内容简介:本文将介绍运行 5 万并发用户测试所需要的步骤(该测试用户量最多可达 200 万)。在开始之前,请先从 JMeter Apache 社区网站(
本文将介绍运行 5 万并发用户测试所需要的步骤(该测试用户量最多可达 200 万)。
步骤概述
- 编写脚本;
- 使用 JMeter 进行本地测试;
- BlazeMeter 沙箱测试;
- 使用一个控制台和一个引擎,设置每个引擎的用户数量;
- 设置和测试集群(一个控制台和 10 到 14 个引擎);
- 使用主从功能达到最大并发量目标。
第 1 步:编写脚本
在开始之前,请先从 JMeter Apache 社区网站( http://jmeter.apache.org/ )获取最新的 JMeter 版本。
下载 JMeter 插件管理器( https://jmeter-plugins.org/wiki/PluginsManager/ )。下载好 JAR 文件后,将其放入 JMeter 的 lib/ext 目录。然后,启动 JMeter,并转到“选项”菜单,找到插件管理器。
你可以通过多种方式获取脚本:
- 使用 BlazeMeter Chrome 插件记录测试步骤;
- 使用 JMeter HTTP(S)测试脚本记录器设置代理,运行测试,并记录所有内容;
- 从头开始手动操作并构建所有内容(主要针对功能 /QA 测试)。
如果你的脚本是通过录制得到(如上面的步骤 1 和 2),请记住:
- 你需要修改某些参数,例如用户名和密码,或者使用包含这些参数的 CSV 文件,这样每个用户都可以是唯一的。
- 你可能需要使用正则表达式、JSON 路径提取器、XPath 提取器来提取各种元素(如 Token-String、Form-Build-Id 等),以便完成“AddToCart”、“Login”之类的请求。
- 保持脚本参数化,并可以使用配置元素(例如 HTTP 请求默认值),以便可以更方便地切换环境。
第 2 步:使用 JMeter 进行本地测试
开始调试脚本,一个线程,进行一次迭代,使用 View Results Tree、Debug Sampler、Dummy Sampler 和打开的 Log Viewer(以防出现 JMeter 错误)。
运行所有的场景(返回 true 和 false),确保脚本可以按预期正常运行。
在使用一个线程成功运行脚本后,将线程数提升到 10 到 20 个,时间为 10 分钟:
- 如果你希望每个用户都是唯一的——结果是这样的吗?
- 有发生任何错误吗?
- 如果你正在进行注册过程测试,请看一下后端——是否根据你的模板创建了帐户?它们是唯一的吗?
- 从摘要报告中可以看到有关测试的统计信息——它有意义吗?找到平均响应时间、错误、命中率 / 秒。
在脚本准备好之后:
- 删除 Debug/Dummy Samplers 和脚本监听器;
- 如果你使用了监听器(例如“将响应保存到文件”),请确保没有使用任何路径!对于监听器或 CSV 数据集配置,请确保没有使用本地路径。相反,只使用文件名,就好像它与脚本位于同一文件夹中一样。
- 如果你使用了专有的 JAR 文件,请务必将它上传。
- 如果你使用了多个线程组(或不是默认线程组),请确保在将其上传到 BlazeMeter 之前设置好这些值。
第 3 步:BlazeMeter 沙箱测试
如果这是你的第一次测试,应该阅读一下这篇文章( http://community.blazemeter.com/knowledgebase/articles/65152-adding-a-new-jmeter-test-plan ),了解如何在 BlazeMeter 中创建测试。
沙箱允许你对脚本和后端进行测试,确保 BlazeMeter 一切正常。
首先,按下灰色按钮:选择要控制的 JMeter 引擎,以便完全控制测试参数。
你可能会遇到的常见问题包括:
- 防火墙——确保你的环境对 BlazeMeter CIDR 列表(正在不时更新)是开放的,并将它们列入白名单;
- 确保所有测试文件(例如 CSV、JAR、JSON、User.properties 等)都在;
- 确保没有使用任何本地路径。
如果还有问题,请查看日志中的错误(你应该可以下载整个日志)。
沙箱配置可以是这样的:
- 引擎:仅限控制台(一个控制台,0 个引擎)
- 线程:50-300
- 加速时间:20 分钟
- 迭代:永远
- 持续时间:30-50 分钟
你可以在加速期间获得足够的数据,分析一下结果,确保脚本按预期执行。
你应该看一下 Waterfall/WebDriver 选项卡,看看请求是否正常。这个时候你应该不会遇到任何错误(除非你是有意的)。
另外,还要看一下监控选项卡,看看使用了多少内存和 CPU——这有助你完成步骤 4,到时你可以尝试设置每个引擎的用户数。
第 4 步:使用一个控制台和一个引擎设置每个引擎的用户数量
在确信脚本可以在 BlazeMeter 中完美运行之后,我们需要弄清楚一个引擎可以支持多少用户。
如果你能够使用沙箱数据来确定,那就太好了!
我将为你提供一种方法来解决这个问题,无需查看沙箱测试数据。
将测试配置设置为:
- 线程数:500
- 加速时间:40 分钟
- 迭代:永远
- 持续时间:50 分钟
接下来,使用一个控制台和一个引擎。
运行测试,并通过监控选项卡监控测试引擎。
如果你的引擎没有达到 75%的 CPU 利用率或 85%的内存使用率(可以忽略一次性峰值):
- 将线程数改为 700,并再次运行测试;
- 提高线程数,直到获得 1000 个线程或 60%的 CPU/ 内存使用率。
如果你的引擎超过了 75%的 CPU 利用率或 85%的内存使用率(可以忽略一次峰值):
- 注意第一次达到 75%的时间点,然后查看当时有多少用户。
- 再次运行测试,这次使用从上一次测试中获得的用户数量。
- 这一次,使用实际测试的加速时间(5 到 15 分钟是一个不错的值),并将持续时间设置为 50 分钟。
- 确保在整个测试过程中不要超过 75%的 CPU 或 85%的内存使用率。
为了安全起见,可以为每个引擎减少 10%的线程数。
第 5 步:设置和测试集群
我们现在知道一个引擎可以支持多少线程。在这一步结束时,我们将知道一个集群(测试)可以支持的用户数量。
集群是一种逻辑容器,只有一个控制台和 0 到 14 个引擎。当使用超过 14 个引擎时,它实际上会创建两个集群(控制台数量会增加)并克隆你的测试。
每个控制台最多 14 个引擎是基于 BlazeMeter 的测试得出的结果,可以确保控制台能够处理 14 个引擎的压力。
因此,在这个步骤中,我们将采用步骤 4 的测试,只是将引擎的数量增加到 14。
在测试运行时,请转到监控选项卡,并验证:
- 不会有引擎超过 75% CPU 或 85%内存限制;
- 找到控制台标签。转到日志选项卡 -> 网络信息,查找控制台的私有 IP,这样就可以找到控制台的名称。它不应达到 75% CPU 或 85%内存限制。
如果控制台达到了这些限制,请减少引擎数量,并再次运行测试,直到控制台处于这些限制范围内。
在这个步骤结束时,你就会知道:
- 每个集群可以支持的用户数量;
- 每个集群可以达到的命中次数。
在负载结果图下的聚合表中查找其他统计信息,获取有关集群吞吐量的更多信息。
第 6 步:使用主从功能达到最大并发量目标
我们已经到了最后一个阶段。
我们已经知道脚本可以正常运行,还知道一个引擎可以支持多少用户以及一个集群可以支持多少用户。
我们假设有这些值:
- 一个引擎可以支持 500 个用户;
- 集群将有 12 个引擎;
- 我们的目标是进行 5 万用户的测试。
因此,我们需要创建 50000(500 * 12) = 8.3 个集群。
我们可以使用 8 个包含 12 个引擎(4 万 8)的集群和一个包含 4 个引擎(另外 2 千)的集群。但是,最好可以像这样分布负载:
我们将为每个集群使用 10 个引擎,而不是 12 个,这样每个集群的用户数可以达到 10 * 500 = 5 千。然后再使用 10 个集群,就可以达到 5 万的规模。
这将有助于我们:
- 不需要维护两种不同的测试类型;
- 可以通过简单地复制现有的集群每次增长 5 千(5 千比 6 千更常见);
- 如果有需要,我们可以随时添加更多的集群。
我们现在准备好用 5 万用户创建最终的主从测试:
- 将测试名称从“My prod test”更改为“My prod test - slave 1”。
- 我们回到第 5 步,在高级测试属性里将 Standalone 更改为 Slave。
- 保存,我们现在有九个从集群测试和一个主集群测试。
- 回到“My prod test -slave 1”。
- 按复制。
- 现在,重复步骤 1 到 5,直到创建完所有的九个从集群测试。
- 回到“My prod test - slave 9”,并按下复制。
- 将测试名称改为“My prod test -Master”。
- 转到高级测试属性,并将 Slave 改为 Master。
- 检查刚刚创建的所有从集群测试并按保存。
针对 5 万用户的主从测试已准备就绪了。按下主测试的开始按钮,将启动 10 个测试(一个主测试和九个从测试),每个测试有 5 千个用户。
你可以将每个测试(从测试或主测试)更改为来自不同的区域,具有不同的脚本 /csv/ 其他文件,使用不同的网络模拟器或不同的参数。
主测试和从测试的汇总报告将在主测试报告中的一个叫作“Master load results”的新选项卡中找到,打开这个报告就可以看到每个测试的结果。
英文原文: https://dzone.com/articles/how-to-run-a-load-test-of-50k-concurrent-users
以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持 码农网
猜你喜欢:- 如何运行50k +并发用户的负载测试
- 3分钟了解负载均衡,分清二层负载均衡和三层负载均衡
- 负载均衡策略之有限负载一致性哈希
- 负载均衡之软硬件负载均衡的优缺点
- 医疗信息系统高负载如何应对?找准东华负载均衡
- 性能大比拼-真实世界工作负载vs实验室综合工作负载
本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。
Game Programming Patterns
Robert Nystrom / Genever Benning / 2014-11-2 / USD 39.95
The biggest challenge facing many game programmers is completing their game. Most game projects fizzle out, overwhelmed by the complexity of their own code. Game Programming Patterns tackles that exac......一起来看看 《Game Programming Patterns》 这本书的介绍吧!