共计 4006 个字符，预计需要花费 11 分钟才能阅读完成。
作者：blazemeter
起源：t.cn/ES7KBkW
- 步骤 1 : 编写你的脚本
- 步骤 2 : 应用 JMeter 进行本地测试
- 步骤 3 : BlazeMeter 沙箱测试
- 步骤 4 : 应用 1 个控制台和 1 个引擎来设置每个引擎用户的数量
- 步骤 5 : 装置并测试集群
- 步骤 6 : 应用 Master / Slave 个性来达成你的最大 CC 指标
本文将从负载测试的角度，形容了做一次晦涩的 5 万用户并发测试须要做的事件.
你能够在本文的结尾局部看到探讨的记录.
疾速的步骤概要
- 编写你的脚本
- 应用 JMeter 进行本地测试
- BlazeMeter 沙箱测试
- 应用一个控制台和一个引擎设置 Users-per-Engine 的数量
- 设置并测试你的汇合 (1 个控制台和 10-14 引擎)
- 应用 Master / Slave 个性来达成你的最大 CC 指标
步骤 1 : 编写你的脚本
开始之前，请确定从 JMeter 的 Apache 社区 jmeter.apache.org 取得了最新的版本.
你也会要下载这些附加的插件，因为它们能够让你的工作更轻松.
有许多办法能够取得脚本:
- 应用 BlazeMeter 的 Chrome 扩大 来记录你的计划
- 应用 JMeter HTTP(S) 测试脚本记录器 来设置一个代理，那样你就能够运行你的测试并记录下所有的货色
- 从头开始全副手工构建(可能是性能 /QA 测试)
如果你的脚本是一份记录的后果(像步骤 1 &2), 请牢记:
- 你须要扭转诸如 Username & Password 这样的特定参数，或者你兴许会想要设置一个 CSV 文件，有了外面的值每个用户就能够是不同的.
- 为了实现诸如“增加到购物车”，“登录”还有其它这样的申请，你兴许要应用正则表达式，JSON 门路提取器，XPath 提取器，来提取诸如 Token 字符串，表单构建 ID 还有其它因素
- 放弃你的脚本参数化，并应用配置元素，诸如默认 HTTP 申请，来使得在环境之间切换时你的工作更轻松.
步骤 2 : 应用 JMeter 进行本地测试
在 1 个线程的 1 个迭代中应用查看后果树因素，调试样本，虚构样本还有关上的日志查看器（一些 JMeter 的谬误会在外面报告），来调试你的脚本.
遍历所有的场景(包含 True 或者 False 的回应) 来确保脚本行为确如预期…
在胜利应用一个线程测试之后——将其进步到 10 分钟 10 到 20 个线程持续测试:
- 如果你想要每个用户独立——是那样的么?
- 有没有收到谬误?
- 如果你在做一个注册过程，那就看看你的后盾 – 账户是不是照你的模板创立好了? 它们是不是独立的呢?
- 从总结报告中，你能够看到对测试的统计 – 它们有点用么? (均匀响应工夫, 谬误, 每秒命中率)
一旦你筹备好了脚本:
- 通过移除任何调试和虚构样本来清理脚本，并删除你的脚本侦听器
- 如果你应用了侦听器(诸如 “ 将响应保留到一个文件 ”)，请确保你没有应用任何门路! , 而如果他是一个侦听器或者一个 CSV 数据集配置——请确保你没有应用你在本地应用的门路 – 而只有文件名(就如同跟你的脚本在同一个文件夹)
- 如果你应用了本人专有的 JAR 文件，请确保它也被上传了.
- 如果你应用了超过一个线程组（不是默认的那个) – 请确保在将其上传到 BlazeMeter 之前设置了这个值.
步骤 3 : BlazeMeter 沙箱测试
如果那时你的第一个测试——你应该复习一下 这篇 无关如何在 BlazeMeter 中创立测试的文章.
将沙箱的测试配置设置成，用户 300，1 个控制台, 工夫 50 分钟.
对沙箱进行这样的配置让你能够在后盾测试你的脚本，并确保上的 BlazeMeter 的所有都运行完整
为此，先按下灰色的按钮: 通知 JMeter 引擎我想要齐全管制! – 来取得对你的测试参数的齐全管制
通常你将会遇到的问题:
- 防火墙 – 确保你的环境对 BlazeMeter 的 CIDR 列表 (它们会实时更新)开发，并把它们放入白名单中
- 确保你所有的测试文件, 比方: CSVs, JAR, JSON, User.properties 等等.. 都能够应用
- 确保你没有应用任何门路
如果依然有问题，那就看看谬误日志吧 (你应该能够把整个日志都下载下来).
一个沙箱的配置能够是这样的:
- 引擎: 是能使控制台(1 个控制台 , 0 个引擎)
- 线程: 50-300
- 产能晋升: 20 分钟
- 迭代: 始终测试上来
- 工夫: 30-50 分钟
这能够让你在产能晋升期间取得足够多的数据(以防你遇到问题)，而你将能够对后果进行剖析，以确保脚本的执行确如预期.
你应该察看下 Waterfall / WebDriver 选项卡来看看申请是否失常，你不应该在这一点上出任何问题（除非你是成心的).
你应该盯着监控选项卡，观察期内存和 CPU 耗费 – 这对你在步骤 4 中尝试设置每一个引擎的用户数量.
步骤 4 : 应用 1 个控制台和 1 个引擎来设置每个引擎用户的数量
当初咱们能够必定脚本能在 BlazeMeter 中完满运行了——咱们须要计算出要多少用户放到一个引擎中.
如果你能用户沙箱中的数据来做这个决定，那就太棒了!
在这里，我会给出一种不必回头去查看沙箱测试数据就能计算出这个数的办法.
设置你的测试配置:
- 线程数: 500
- 产能晋升：40 分钟
- 迭代: 永恒
- 时长: 50 分钟
应用一个控制台和一个引擎.
运行测试并 (通过监督选项卡) 对你的测试引擎进行监督.
如果你的引擎对于 75% 的 CPI 使用率和 85% 的内存使用率都没有达到(一次性的峰值能够疏忽) 的话:
- 将线程数调整到 700 在测试一次
- 提交线程的数量直到线程数达到 1000 或者 60% 的 CPU 或内存应用
- 如果你的引擎过了 75% 的 CPU 使用率或者 85% 的内存使用率(一次性的峰值能够疏忽 :
- 看看你第一次达到 75% 的点，在那个点有多少并发用户.
- 在运行一次测试, 而不是进步你之前 500 个用户数量的产能
- 这一次将产能晋升放到实在的测试中(5-15 分钟是一个好的开始) 并将时长设置为 50 分钟.
- 确保整个测试过程中没有超过 75% 的 CPU 使用率或者 85% 的内存使用率…
为平安起见，你能够把每个引擎的线程数 升高 10% 的.
步骤 5：装置并测试集群
咱们当初晓得了从一个引擎中咱们失去了多少线程，在该章节的最初，咱们将会晓得一个集群能给咱们提供多少用户。
一个集群是指具备一个控制台（仅有一个）和 0 -14 个引擎的逻辑容器。
即便你能够创立一个应用超过 14 个引擎的测试案例——但实际上是创立了两个集群（你能够留神到控制台的数量减少了），并且克隆了你的测试案例……
每个集群具备最多 14 个引擎，是基于 BlazeMeter 本人自身的测试，以确保控制台能够管制这 14 台引擎对新建的大量数据处理的压力。
所以在这一步骤中，咱们会用步骤 4 种的测试，并且仅仅批改引擎数量，将其减少到 14.
将该测试依照最终测试的全副时长运行。当测试在运行时，关上监听标签，并且测验：
- 没有一个引擎超过 CPU75% 的占有率和内存 85% 占有率的下限；
- 定位你的控制台标签（你能够通过一次点击 Logs Tab->Network Information，查看控制台公有 IP 地址来找到它的名字）——它不应该达到 CPU75% 占有率和内存 85% 占有率的下限。
如果你的控制台达到了该下限——缩小引擎数量并从新运行直到控制台在该下限之下。
在这个步骤的最初，你会发现：
- 每个集群的用户数量；
- 每个集群的命中率。
查看 Aggretate Table 中的其余统计信息，并找到本地后果统计图来取得无关你集群吞吐量的更多信息。
步骤 6 : 应用 Master / Slave 个性来达成你的最大 CC 指标
咱们到了最初一步了。
咱们晓得脚本正在运行，咱们也晓得一个引擎能够反对多少用户以及一个集群能够反对多少用户。
让咱们做一下假如：
- 一个引擎反对 500 用户
- 一个集群能够用户 12 个引擎
- 咱们的指标是 5 万用户测试
因而为了实现这些，咱们须要 8.3 个集群..
咱们能够用 8 个 12 台引擎的集群和一个 4 太引擎的集群 – 然而像上面这样扩散负载应该会更好：
每个集群咱们用 10 台引擎而不是 12，那么每个集群能够反对 10*500 = 5K 用户并且咱们须要 10 个集群来反对 5 万用户。
这样能够失去如下益处：
- 不必保护两个不同的测试类型
- 咱们能够通过简略的复制现有集群来减少 5K 用户（5K 比 6K 更常见）
- 只有须要咱们能够始终减少
当初，咱们曾经筹备好创立最终的 5 万用户级别的 Master / Slave 测试了：
- 将测试的名称从 ”My prod test” 改为 ”My prod test – slave 1″。
- 咱们回到步骤 5，将高级测试属性 (Advanced Test Properties) 下的 Standalone 批改为 Slave。
- 按保留按钮——当初咱们有了一个 Master 和 9 个 Slave 中的一个。
- 返回你的 “My prod test -slave 1”.
- 按复制按钮
- 接下来反复步骤 1 - 5 直到你创立了 9 个 slave。
- 回到你的 “My prod test -salve 9” 并按复制按钮.
- 将测试的名称改为 “My prod test -Master”.
- 将高级测试属性(Advanced Test Properties) 下的 Slave 改为 Master。
- 查看咱们方才创立的所有的 Slave(My prod test -salve 1..9)并按保留。
你的 5 万用户级别的 Master-Slave 测试曾经筹备好了。通过按 master 上的开始按钮来运行 10 个测试，每个测试 5 千用户。
你能够批改任意一个测试（salve 或 master），让它们来自不同的区域，有不同的脚本 /csv/ 以及其余文件，应用不同的网络模拟器，不同的参数等。
你能够在一个叫“Master load results”的 master 报告中的一个新 tab 页中找到生成的聚合后果的报告，你还能够通过关上单个的报告来独立的查看每一个测试后果。
学习材料分享
12 套 微服务、Spring Boot、Spring Cloud 核心技术材料，这是局部材料目录：
- Spring Security 认证与受权
- Spring Boot 我的项目实战（中小型互联网公司后盾服务架构与运维架构）
- Spring Boot 我的项目实战（企业权限治理我的项目））
- Spring Cloud 微服务架构我的项目实战（分布式事务解决方案）
- …
公众号后盾回复
arch028获取材料：：
