如何使用jmeter来实现更大批量的并发的解决方案

近期在用JMeter进行负载测试的 时候，发现使用单台机器模拟测试超过比如500个进程的并发就有些力不从心或者说不能如实的反应实际情况，在执行的过程中，JMeter自身会自动关闭， 要解决这个问题，则可以使用分布式测试，运行多台机器运行所谓的 Agent 来分担 JMeter自身的压力（这个和LODARUNNER是一样的道理），并借此来获取更大的并发用户数,则需要进行相关的配置参数和文件权限进行一些修改， 具体如下：
　　1、在所有期望运行 JMeter 并作为 Load Generator 的机器上安装 JMeter，并确定其中一台机器作为 Controller，其他的机器作为 Agent——假定我们使用两台机器 192.168.0.1 和 192.168.0.2 作为 Agent；
　　2、在Controller 机器的 JMeter 安装目录下找到 bin 目录，再找到 JMeter.properties 这个文件，使用记事本或者其他文字编辑工具打开它；
　 　3、在打开的文件中查找“remote_hosts=”这个字符串，你可以找到这样一行“remote_hosts=127.0.0.1”。其 中的 127.0..0.1 表示运行 JMeter Agent 的机器，这里需要修改为“remote_hosts=192.168.0.1:1099,192.168.0.2:1099”——其中的 1099 为 JMeter 的 Controller 和 Agent 之间进行通讯的默认 RMI 端口号； （个人备注：只改要作为Controller的机器上的此文件即可；Agent的机器上的文件可以不理会）
　　4、保存文件，然后依次启动作为 Controller的机器上的jmeter-server文件和作为Agent的机器上的jmeter-server文件（个人备注：如果是 WINDOWS系统版本的jmeter，则是启动jmeter-server.bat的批处理文件，LINUX系统则是jmeter-server文件， 没有后缀的，但是要修改为可执行权限，这后面具体有提到），并重新启动 Controller 机器上的 JMeter.bat，并进入 Run -> Remote Start 菜单项，在这里可以看到远程启动菜单下面有192.168.0.1 ，192.168.0.1两个IP地址
　　5、如果要让某个电脑执行，可以点击改电脑的IP地址就可以，如果两个都要执行，可以点击Run 菜单下的“远程运行全部”菜单
　 　6、有时候用作代理的机器太少，仍不能满足需要，则需要将作为Controller的电脑也当作Agent，则同样需要修改 JMeter.properties文件，将Controller的IP地址写入。同时，这个时候，需要打先打开Controller 电脑中JMeter下bin目录下的jmeter-server.bat，然后再打开JMeter.bat，此时，进入Run -> Remote Start菜单，可以看到Controller也作为远程机器进行运行。 （针对第六点我个人经过实地测试后要进行细化确认：如果是在LINUX下，此文件的权限都还是要修改的，且jmeter-server会调用名为 jmeter脚本文件，其jmeter文件的权限也要修改为可执行的才可以，且每个被调用的Agent的机器的jmeter-server文件也是要执行 中才可用调用，这点很重要。）。

 

一台机器可压测的用户数：

对并发线程的支持基本上取决于许多因素，如操作系统、空闲RAM和连接。

这是基于我的经验，如果我们按照下面的最佳实践，那么我们可以实现350 ~ 500并发用户(基于web的应用程序)和900~1100并发用户(后端API)提供8 GB RAM 64位操作系统。

使用最新版本的JMeter

使用正确的线程数量

使用脚本参数化和相关性

使用CLI模式，禁用/删除监听器，通过XML删除CSV，减少断言

在线程和线程组之间使用变量共享

放置cookie，授权管理器

不要使用功能模式

不要修改jmeter。属性而不是修改用户。属性文件

不要使用不赞成使用的元素

注意:如果您观察到CPU超过80%，那么这不是一个好迹象。您应该尽量减少并发用户数量并重新运行脚本。

 

示例：

本文将从负载测试的角度，描述了做一次流畅的5万用户并发测试需要做的事情.

你可以在本文的结尾部分看到讨论的记录.

快速的步骤概要

1. 编写你的脚本

2. 使用JMeter进行本地测试

3. BlazeMeter沙箱测试

4. 使用一个控制台和一个引擎设置Users-per-Engine的数量

5. 设置并测试你的集合 (1个控制台和10-14 引擎)

6. 使用 Master / Slave 特性来达成你的最大CC目标

步骤一1 : 编写你的脚本

开始之前，请确定从JMeter的Apache社区jmeter.apache.org 获得了最新的版本.

你也会要下载这些附加的插件 ，因为它们可以让你的工作更轻松.

有许多方法可以获得脚本:

1. 使用 BlazeMeter 的 Chrome 扩展 来记录你的方案

2. 使用 JMeter HTTP(S) 测试脚本记录器 来设置一个代理，那样你就可以运行你的测试并记录下所有的东西

3. 从头开始全部手工构建(可能是功能/QA测试)

如果你的脚本是一份记录的结果(像步骤1&2), 请牢记:

1. 你需要改变诸如Username & Password这样的特定参数，或者你也许会想要设置一个CSV文件，有了里面的值每个用户就可以是不同的.

2. 为了完成诸如“添加到购物车”，“登录”还有其它这样的请求，你也许要使用正则表达式，JSON路径提取器，XPath提取器，来提取诸如Token字符串，表单构建ID还有其它要素

3. 保持你的脚本参数化，并使用配置元素，诸如默认HTTP请求，来使得在环境之间切换时你的工作更轻松.

回到顶部

步骤2 : 使用JMeter进行本地测试

在1个线程的1个迭代中使用查看结果树要素，调试样本，虚拟样本还有打开的日志查看器（一些JMeter的错误会在里面报告），来调试你的脚本.

遍历所有的场景(包括True 或者 False的回应) 来确保脚本行为确如预期...

在成功使用一个线程测试之后——将其提高到10分钟10到20个线程继续测试:

1. 如果你想要每个用户独立——是那样的么?

2. 有没有收到错误?

3. 如果你在做一个注册过程，那就看看你的后台 - 账户是不是照你的模板创建好了? 它们是不是独立的呢?

4. 从总结报告中，你可以看到对测试的统计 - 它们有点用么? (平均响应时间, 错误, 每秒命中率)

一旦你准备好了脚本:

1. 通过移除任何调试和虚拟样本来清理脚本，并删除你的脚本侦听器

2. 如果你使用了侦听器(诸如 "将响应保存到一个文件")，请确保你没有使用任何路径! , 而如果他是一个侦听器或者一个CSV数据集配置——请确保你没有使用你在本地使用的路径 - 而只要文件名(就好像跟你的脚本在同一个文件夹)

3. 如果你使用了自己专有的JAR文件，请确保它也被上传了.

4. 如果你使用了超过一个线程组（不是默认的那个) - 请确保在将其上传到BlazeMeter之前设置了这个值.

回到顶部

步骤3 : BlazeMeter沙箱测试

如果那时你的第一个测试——你应该温习一下 这篇 有关如何在BlazeMeter中创建测试的文章.

将沙箱的测试配置设置成，用户300，1个控制台, 时间50分钟.

对沙箱进行这样的配置让你可以在后台测试你的脚本，并确保上的BlazeMeter的一切都运行完好.

为此，先按下灰色的按钮: 告诉JMeter引擎我想要完全控制! - 来获得对你的测试参数的完全控制

通常你将会遇到的问题:

1. 防火墙 - 确保你的环境对BlazeMeter的CIDR 列表 (它们会实时更新)开发，并把它们放入白名单中

2. 确保你所有的测试文件, 比如: CSVs, JAR, JSON, User.properties 等等.. 都可以使用

3. 确保你没有使用任何路径

如果仍然有问题，那就看看错误日志吧(你应该可以把整个日志都下载下来).

一个沙箱的配置可以是这样的:

• 引擎: 是能使控制台(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.

将该测试按照最终测试的全部时长运行。当测试在运行时，打开监听标签，并且检验：

    1. 没有一个引擎超过CPU75%的占有率和内存85%占有率的上限；

    2. 定位你的控制台标签（你可以通过一次点击Logs Tab->Network Information，查看控制台私有IP地址来找到它的名字）——它不应该达到CPU75%占有率和内存85%占有率的上限。

如果你的控制台达到了该上限——减少引擎数量并重新运行直到控制台在该上限之下。

在这个步骤的最后，你会发现：

    1. 每个集群的用户数量；

    2. 每个集群的命中率。

查看Aggretate Table中的其他统计信息，并找到本地结果统计图来获得有关你集群吞吐量的更多信息。

回到顶部

步骤 6 : 使用 Master / Slave 特性来达成你的最大CC目标

我们到了最后一步了。

我们知道脚本正在运行，我们也知道一个引擎可以支持多少用户以及一个集群可以支持多少用户。

让我们做一下假设：

• 一个引擎支持500用户

• 一个集群可以用户12个引擎

• 我们的目标是5万用户测试

因此为了完成这些，我们需要8.3 个集群..

我们可以用8个12台引擎的集群和一个4太引擎的集群 - 但是像下面这样分散负载应该会更好：

每个集群我们用10台引擎而不是12，那么每个集群可以支持 10*500 = 5K 用户并且我们需要10个集群来支持5万用户。

这样可以得到如下好处：

1. 不用维护两个不同的测试类型

2. 我们可以通过简单的复制现有集群来增加5K用户（5K比6K更常见）

3. 只要需要我们可以一直增加

现在，我们已经准备好创建最终的5万用户级别的Master / Slave测试了：

1. 将测试的名称从"My prod test" 改为"My prod test - slave 1"。

2. 我们回到步骤5，将高级测试属性(Advanced Test Properties)下的Standalone修改为Slave。

3. 按保存按钮——现在我们有了一个Master和9个Slave中的一个。

4. 返回你的 "My prod test -slave 1".

5. 按复制按钮

6. 接下来重复步骤1-5直到你创建了9个slave。

7. 回到你的 "My prod test -salve 9" 并按复制按钮.

8. 将测试的名称改为 "My prod test -Master".

9. 将高级测试属性(Advanced Test Properties) 下的Slave改为Master。

10. 检查我们刚才创建的所有的Slave(My prod test -salve 1..9)并按保存。

你的5万用户级别的Master-Slave测试已经准备好了。通过按master上的开始按钮来运行10个测试，每个测试5千用户。

你可以修改任意一个测试（salve或master），让它们来自不同的区域，有不同的脚本/csv/以及其他文件，使用不同的网络模拟器，不同的参数等。

你可以在一个叫“Master load results”的master报告中的一个新tab页中找到生成的聚合结果的报告，你还可以通过打开单个的报告来独立的查看每一个测试结果。

来源：https://www.cnblogs.com/zhengah/p/5039273.html