本文将从负载测试的角度，描述了做一次流畅的5万用户并发测试需要做的事情。
你可以在本文的结尾部分看到讨论的记录。
快速的步骤概要
开始之前，请确定从JMeter的Apache社区jmeter.apache.org 获得了最新的版本.
你也会要下载这些附加的插件 ，因为它们可以让你的工作更轻松.
有许多方法可以获得脚本:
如果你的脚本是一份记录的结果(像步骤1&2), 请牢记:
在1个线程的1个迭代中使用查看结果树要素，调试样本，虚拟样本还有打开的日志查看器（一些JMeter的错误会在里面报告），来调试你的脚本.
遍历所有的场景(包括True 或者 False的回应) 来确保脚本行为确如预期…
在成功使用一个线程测试之后——将其提高到10分钟10到20个线程继续测试:
一旦你准备好了脚本:
如果那时你的第一个测试——你应该温习一下 这篇 有关如何在BlazeMeter中创建测试的文章.
将沙箱的测试配置设置成，用户300，1个控制台, 时间50分钟.
对沙箱进行这样的配置让你可以在后台测试你的脚本，并确保上的BlazeMeter的一切都运行完好。
为此，先按下灰色的按钮: 告诉JMeter引擎我想要完全控制! - 来获得对你的测试参数的完全控制。
通常你将会遇到的问题:
如果仍然有问题，那就看看错误日志吧(你应该可以把整个日志都下载下来).
一个沙箱的配置可以是这样的:
这可以让你在产能提升期间获得足够多的数据(以防你遇到问题) ，而你将可以对结果进行分析，以确保脚本的执行确如预期。
你应该观察下Waterfall / WebDriver 选项卡来看看请求是否正常，你不应该在这一点上出任何问题（除非你是故意的)。
你应该盯着监控选项卡，观察期内存和CPU消耗 - 这对你在步骤4中尝试设置每一个引擎的用户数量。
现在我们可以肯定脚本能在BlazeMeter中完美运行了——我们需要计算出要多少用户放到一个引擎中。
如果你能用户沙箱中的数据来做这个决定，那就太棒了!
在这里，我会给出一种不用回头去查看沙箱测试数据就能计算出这个数的方法。
设置你的测试配置:
使用一个控制台和一个引擎.
运行测试并(通过监视选项卡)对你的测试引擎进行监视.
如果你的引擎对于75%的CPI使用率和85%的内存使用率都没有达到(一次性的峰值可以忽略) 的话:
如果你的引擎过了75%的CPU使用率或者85%的内存使用率(一次性的峰值可以忽略 :
为安全起见，你可以把每个引擎的线程数降低10%的.
我们现在知道了从一个引擎中我们得到了多少线程，在该章节的最后，我们将会知道一个集群能给我们提供多少用户。
一个集群是指具有一个控制台（仅有一个）和0-14个引擎的逻辑容器。
即使你可以创建一个使用超过14个引擎的测试案例——但实际上是创建了两个集群（你可以注意到控制台的数量增加了），并且克隆了你的测试案例……
每个集群具有最多14个引擎，是基于BlazeMeter自己本身的测试，以确保控制台可以控制这14台引擎对新建的大量数据处理的压力。
所以在这一步骤中，我们会用步骤4种的测试，并且仅仅修改引擎数量，将其增加到14。
将该测试按照最终测试的全部时长运行。当测试在运行时，打开监听标签，并且检验：
如果你的控制台达到了该上限——减少引擎数量并重新运行直到控制台在该上限之下。
在这个步骤的最后，你会发现：
查看Aggretate Table中的其他统计信息，并找到本地结果统计图来获得有关你集群吞吐量的更多信息。
我们到了最后一步了。
我们知道脚本正在运行，我们也知道一个引擎可以支持多少用户以及一个集群可以支持多少用户。
让我们做一下假设：
因此为了完成这些，我们需要8.3 个集群..
我们可以用8个12台引擎的集群和一个4太引擎的集群 - 但是像下面这样分散负载应该会更好：
每个集群我们用10台引擎而不是12，那么每个集群可以支持 10*500 = 5K 用户并且我们需要10个集群来支持5万用户。
这样可以得到如下好处：
现在，我们已经准备好创建最终的5万用户级别的Master / Slave测试了：
你的5万用户级别的Master-Slave测试已经准备好了。通过按master上的开始按钮来运行10个测试，每个测试5千用户。
你可以修改任意一个测试（salve或master），让它们来自不同的区域，有不同的脚本/csv/以及其他文件，使用不同的网络模拟器，不同的参数等。
你可以在一个叫“Master load results”的master报告中的一个新tab页中找到生成的聚合结果的报告，你还可以通过打开单个的报告来独立的查看每一个测试结果。
转载于：
https://mp.weixin.qq.com/s/9NEg13zLGQnVIroXm7evAw
京公网安备 11010802035086号