精华内容
下载资源
问答
  • 本文将介绍运行 5 万并发用户测试所需要的步骤(该测试用户量最多可达 200 万)。步骤概述编写脚本;...使用主从功能达到最大并发量目标。第 1 步:编写脚本在开始之前,请先从 JMeter Apache 社区网站(http://j...
    3e25c7aea2cb59ac1d9972fdd77bbf48.png

    本文将介绍运行 5 万并发用户测试所需要的步骤(该测试用户量最多可达 200 万)。

    步骤概述

    1. 编写脚本;
    2. 使用 JMeter 进行本地测试;
    3. BlazeMeter 沙箱测试;
    4. 使用一个控制台和一个引擎,设置每个引擎的用户数量;
    5. 设置和测试集群(一个控制台和 10 到 14 个引擎);
    6. 使用主从功能达到最大并发量目标。
    b8d7977e9dfb35c243d98bc4dc4ee3ed.png

    第 1 步:编写脚本

    在开始之前,请先从 JMeter Apache 社区网站(http://jmeter.apache.org/)获取最新的 JMeter 版本。

    下载 JMeter 插件管理器(https://jmeter-plugins.org/wiki/PluginsManager/)。下载好 JAR 文件后,将其放入 JMeter 的 lib/ext 目录。然后,启动 JMeter,并转到“选项”菜单,找到插件管理器。

    你可以通过多种方式获取脚本:

    1. 使用 BlazeMeter Chrome 插件记录测试步骤;
    2. 使用 JMeter HTTP(S)测试脚本记录器设置代理,运行测试,并记录所有内容;
    3. 从头开始手动操作并构建所有内容(主要针对功能 /QA 测试)。

    如果你的脚本是通过录制得到(如上面的步骤 1 和 2),请记住:

    1. 你需要修改某些参数,例如用户名和密码,或者使用包含这些参数的 CSV 文件,这样每个用户都可以是唯一的。
    2. 你可能需要使用正则表达式、JSON 路径提取器、XPath 提取器来提取各种元素(如 Token-String、Form-Build-Id 等),以便完成“AddToCart”、“Login”之类的请求。
    3. 保持脚本参数化,并可以使用配置元素(例如 HTTP 请求默认值),以便可以更方便地切换环境。

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

    开始调试脚本,一个线程,进行一次迭代,使用 View Results Tree、Debug Sampler、Dummy Sampler 和打开的 Log Viewer(以防出现 JMeter 错误)。

    运行所有的场景(返回 true 和 false),确保脚本可以按预期正常运行。

    在使用一个线程成功运行脚本后,将线程数提升到 10 到 20 个,时间为 10 分钟:

    1. 如果你希望每个用户都是唯一的——结果是这样的吗?
    2. 有发生任何错误吗
    3. 如果你正在进行注册过程测试,请看一下后端——是否根据你的模板创建了帐户?它们是唯一的吗?
    4. 从摘要报告中可以看到有关测试的统计信息——它有意义吗?找到平均响应时间、错误、命中率 / 秒。

    在脚本准备好之后:

    1. 删除 Debug/Dummy Samplers 和脚本监听器;
    2. 如果你使用了监听器(例如“将响应保存到文件”),请确保没有使用任何路径!对于监听器或 CSV 数据集配置,请确保没有使用本地路径。相反,只使用文件名,就好像它与脚本位于同一文件夹中一样。
    3. 如果你使用了专有的 JAR 文件,请务必将它上传。
    4. 如果你使用了多个线程组(或不是默认线程组),请确保在将其上传到 BlazeMeter 之前设置好这些值。

    第 3 步:BlazeMeter 沙箱测试

    如果这是你的第一次测试,应该阅读一下这篇文章(http://community.blazemeter.com/knowledgebase/articles/65152-adding-a-new-jmeter-test-plan),了解如何在 BlazeMeter 中创建测试。

    沙箱允许你对脚本和后端进行测试,确保 BlazeMeter 一切正常。

    首先,按下灰色按钮:选择要控制的 JMeter 引擎,以便完全控制测试参数。

    你可能会遇到的常见问题包括:

    1. 防火墙——确保你的环境对 BlazeMeter CIDR 列表(正在不时更新)是开放的,并将它们列入白名单;
    2. 确保所有测试文件(例如 CSV、JAR、JSON、User.properties 等)都在;
    3. 确保没有使用任何本地路径。

    如果还有问题,请查看日志中的错误(你应该可以下载整个日志)。

    沙箱配置可以是这样的:

    • 引擎:仅限控制台(一个控制台,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。

    在测试运行时,请转到监控选项卡,并验证:

    1. 不会有引擎超过 75% CPU 或 85%内存限制;
    2. 找到控制台标签。转到日志选项卡 -> 网络信息,查找控制台的私有 IP,这样就可以找到控制台的名称。它不应达到 75% CPU 或 85%内存限制。

    如果控制台达到了这些限制,请减少引擎数量,并再次运行测试,直到控制台处于这些限制范围内。

    在这个步骤结束时,你就会知道:

    1. 每个集群可以支持的用户数量;
    2. 每个集群可以达到的命中次数。

    在负载结果图下的聚合表中查找其他统计信息,获取有关集群吞吐量的更多信息。

    第 6 步:使用主从功能达到最大并发量目标

    我们已经到了最后一个阶段。

    我们已经知道脚本可以正常运行,还知道一个引擎可以支持多少用户以及一个集群可以支持多少用户。

    我们假设有这些值:

    • 一个引擎可以支持 500 个用户;
    • 集群将有 12 个引擎;
    • 我们的目标是进行 5 万用户的测试。

    因此,我们需要创建 50000(500 * 12) = 8.3 个集群。

    我们可以使用 8 个包含 12 个引擎(4 万 8)的集群和一个包含 4 个引擎(另外 2 千)的集群。但是,最好可以像这样分布负载:

    我们将为每个集群使用 10 个引擎,而不是 12 个,这样每个集群的用户数可以达到 10 * 500 = 5 千。然后再使用 10 个集群,就可以达到 5 万的规模。

    这将有助于我们:

    1. 不需要维护两种不同的测试类型;
    2. 可以通过简单地复制现有的集群每次增长 5 千(5 千比 6 千更常见);
    3. 如果有需要,我们可以随时添加更多的集群。

    我们现在准备好用 5 万用户创建最终的主从测试:

    1. 将测试名称从“My prod test”更改为“My prod test - slave 1”。
    2. 我们回到第 5 步,在高级测试属性里将 Standalone 更改为 Slave。
    3. 保存,我们现在有九个从集群测试和一个主集群测试。
    4. 回到“My prod test -slave 1”。
    5. 按复制。
    6. 现在,重复步骤 1 到 5,直到创建完所有的九个从集群测试。
    7. 回到“My prod test - slave 9”,并按下复制。
    8. 将测试名称改为“My prod test -Master”。
    9. 转到高级测试属性,并将 Slave 改为 Master。
    10. 检查刚刚创建的所有从集群测试并按保存。

    针对 5 万用户的主从测试已准备就绪了。按下主测试的开始按钮,将启动 10 个测试(一个主测试和九个从测试),每个测试有 5 千个用户。

    你可以将每个测试(从测试或主测试)更改为来自不同的区域,具有不同的脚本 /csv/ 其他文件,使用不同的网络模拟器或不同的参数。

    主测试和从测试的汇总报告将在主测试报告中的一个叫作“Master load results”的新选项卡中找到,打开这个报告就可以看到每个测试的结果。

    英文原文:https://dzone.com/articles/how-to-run-a-load-test-of-50k-concurrent-users

    展开全文
  • 我之前用Jmeter测试了,4G内存只能支持20多个线程并行下载,数量一多就报内存已满,我的电脑内存是8G的,jmeter参数已经调置最大,还能用什么方法测试?测试完成之后,怎么根据那些数据分析Tomcat的下载性能?
  • 原标题:如何进行 5 万并发用户负载...使用 JMeter 进行本地测试;BlazeMeter 沙箱测试;使用一个控制台和一个引擎,设置每个引擎的用户数量;设置和测试集群(一个控制台和 10 到 14 个引擎);使用主从功能达到最...

    原标题:如何进行 5 万并发用户负载测试?超实用步骤详解

    作者 | Refael Botbol

    编辑 | 张婵

    本文将介绍运行 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返回搜狐,查看更多

    责任编辑:

    展开全文
  • 快速的步骤概要编写你的脚本使用JMeter进行本地测试BlazeMeter沙箱测试使用一个控制台和一个引擎设置Users-per-Engine的数量设置并测试你的集合(1个控制台和10-14 引擎)使用 Master / Slave 特性来达成你的最大CC...

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

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

    快速的步骤概要

    编写你的脚本

    使用JMeter进行本地测试

    BlazeMeter沙箱测试

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

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

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

    步骤一1 : 编写你的脚本

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

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

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

    使用 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.

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

    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万用户。

    这样可以得到如下好处:

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

    我们可以通过简单的复制现有集群来增加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页中找到生成的聚合结果的报告,你还可以通过打开单个的报告来独立的查看每一个测试结果。

    展开全文
  • 使用jmeter如何测试服务器最大并发数? 通过增大并发数量,见识服务器的吞吐量吗?
  • Jmeter性能测试简介

    2021-04-06 17:46:12
    XXX 认证要求测试合作伙伴的 APP服务器性能,主要涉及 APP服务器最大的并发请求消息处理能力,根据《XXX 认证解决方案设计说明书》里的要求,APP服务器并发数量为 2500 packet/s,即在 10 秒内的第 1 秒达到 2500 ...

    1. 背景介绍

    XXX 认证要求测试合作伙伴的 Web服务器性能,主要涉及 APP服务器最大的并发请求消息处理能力,根据《XXX 设计说明书》里的要求,Web服务器并发数量为 2500 packet/s。

    2. 测试需求

    Web服务器并发请求消息处理能力为 2500 packet/s

    3. 测试用例

    名称 预置条件 测试步骤 预期结果
    Web服务器处理北向推送数据的能力 1.在公有云上完成Web服务器的部署2.在公有云上的IoT平台上传profile/publicKey/插件/CA证书3.完成Web服务器和IoT平台的对接4.在Web服务器上按顺序开户30万5.提供开户的IMEI和终端的payload信息给IOT平台测试人员,IOT平台测试人员将信息写入性能测试工具Jmeter中 启动Jmeter性能测试工具,以2500packet/s对APP服务器发https包,持续发送120秒 120秒后,在Web服务器能够查询到300,000条数据

    4. 测试组网

    Web服务器 和 Jmeter 安装在同一台 服务器或者服务器里的不同虚拟机里,2 个虚拟机通过内部的交换机互连。

    5. Web服务器性能测试话务模型要求

    话务模型需要对应场景的SA 提供,以X表为例,当前 SA 提供的话务模型是2500 packet/s,持续 2 分钟。

    6. 性能测试对Web服务器的要求

    6.1 Web服务器部署位置

    Web服务器需要部署在实验室内网,以减少外网(比如 Internet)传输丢包对性能测试的影响。

    6.2 Web服务器配置要求

    Web服务器的配置需要测试厂家提供,一般包含前置机/业务机/数据库等。
    前置机:16 核/32G/200G SATA
    业务机:16 核/32G/200G SATA
    数据库:16 核/32G/200G SATA
    操作系统:CentOS 7.3/Window server 2008 等

    6.3 Web服务器开放权限

    Web 需要提供跟 IoT 平台对接时的 API 回调接口用于 Web 性能测试

    7. 软件获取和安装

    7.1 Jemeter 下载链接

    http://jmeter.apache.org/download_jmeter.cgi

    7.2 Jemeter 下载 zip 或者 tgz 任意格式都可以

    在这里插入图片描述

    7.3 Jmeter 安装

    解压后,在下面的目录打开 Jmeter5.0
    \apache-jmeter-5.0\bin
    在这里插入图片描述

    7.4 Jmeter 插件管理器下载链接

    https://jmeter-plugins.org/install/Install/
    在这里插入图片描述

    7.5 Jmeter 插件管理器安装

    将下载的插件管理器 jmeter-plugins-manager-1.3.jar 拷贝到 Jmeter 的安装目录下X:\apache-jmeter-5.0\lib\ext
    在这里插入图片描述在这里插入图片描述

    7.5 Jmeter 步长插件学习资料

    https://blog.csdn.net/u011541946/article/details/71194990

    8.JMeter GUI 图形界面测试

    8.1 选择 GUI 图形界面语言

    点击【Options】,选择【Choose Language】-【Chinese(Simplified)】
    在这里插入图片描述

    8.2 JMeter 按钮介绍

    在这里插入图片描述

    8.3 建立测试任务

    建立线程组—>建立 HTTP 请求—>建立 HTTP 信息头管理器—>建立聚合报告—>建立查看结果树

    8.3.1 建立线程组

    右键点击【测试计划】,选择【添加】-【线程(用户)】-【线程组】
    在这里插入图片描述在这里插入图片描述

    8.3.2 建立 HTTP 请求

    右键点击【线程组】,选择【添加】-【取样器】-【HTTP 请求】
    在这里插入图片描述在这里插入图片描述

    8.3.3 建立 HTTP 信息头管理器

    右键点击【HTTP 请求】,选择【添加】-【配置元件】-【HTTP 信息头管理】
    在这里插入图片描述在这里插入图片描述

    8.3.4 建立聚合报告

    右键点击【HTTP 请求】,选择【添加】-【监听器】-【聚合报告】
    在这里插入图片描述在这里插入图片描述

    8.3.5 建立察看结果树

    右键点击【HTTP 请求】,选择【添加】-【监听器】-【察看结果树】

    在这里插入图片描述在这里插入图片描述

    8.4 测试任务参数填写

    8.4.1 线程组参数填写

    在这里插入图片描述

    8.4.2 HTTP 请求参数填写

    在这里插入图片描述在这里插入图片描述

    8.4.3 HTTP 信息头管理器参数填写

    在 IOT 平台上将 APP 的消息推送改为 http 方式,然后点击确认。
    在 APP服务器上用 fiddler或者wireshark 抓包,可以看到 protocol 类型为 HTTP 的 POST 消息,将消息中的Request Headers消息填写到 JMeter 的信息头管理器中,消息名称的上下顺序不限。
    在这里插入图片描述
    在这里插入图片描述在这里插入图片描述

    8.4.4 聚合报告参数说明

    在这里插入图片描述

    8.4.5 查看结果树参数说明

    在这里插入图片描述

    9.JMeter 命令行测试

    E:\apache-jmeter-5.4.1\bin\jmeter.bat -n -t E:\HTTP请求.jmx -l result.jtl -e -o e:\Web_HttpsReport

    在这里插入图片描述

    10. 自动生成测试报告

    上面的命令将测试报告输出到 E盘根目录下,打开测试报告文件夹下的 index.html 文
    件,可以看到测试报告。测试报告主要关注 3 个指标,Average Response Times ,Throughput , Error%,要保证
    Error 错误率为 0%,然后观察 Throughput 的值和Average Response Times是否满足要求。

    在这里插入图片描述

    11. FAQ

    11.1 Jmeter 产生 address already in use 的异常处理方法解决方案:

    1. 在运行JMeter的机器上添加注册表条目MaxUserPort和TcpTimedWaitDelay,分别设
      置值为65534、30,以增大可分配的tcp连接端口数、减小处于TIME_WAIT状态的
      连接的生存时间。
    2. cmd中,用regedit打开注册表
    3. 在 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters下 1)右击parameters,添加一个新的DWORD,名字为MaxUserPort
      2)双击MaxUserPort,输入数值数据为65534,基数选择十进制
    1. 右击parameters,添加一个新的DWORD,名字为TcpTimedWaitDelay
      4) 双击TcpTimedWaitDelay,输入数值数据为30,基数选择十进制
    1. 然后重启电脑!

    11.2 Jmeter 在每个线程中只发送一条数据,然后就拆链的处理方法解决方案:

    1. Jmeter在每个线程中只发送一条数据,然后就拆链了,导致throughput达不到1500TPS以上,在【HTTP请求】的【高级】里将【实现】改成Java,设置连接和响应超时为10000ms后,JMeter可以在每个线程中发送多条数据。

    11.3 Jmeter 同时发送多条建链请求【SYN】,APP 侧会丢弃部分【SYN】,导致 JMeter 重传【SYN】解决方案:

    1. tcp_max_syn_backlog是指定所能接受SYN同步包的最大客户端数量,即半连接上限;
    2. somaxconn是指服务端所能accept即处理数据的最大客户端数量,即完成连接上限。
    3. 这两个参数的默认值都是1024,需改为16384。
    4. 把参数添加到/etc/sysctl.conf中,然后执行sysctl -p使参数永久生效。

    JMeter侧抓包:
    JMeter侧抓包可以看到第1次发送【SYN】后,由于Web服务器没有响应导致3秒后重传,第2次发
    送【SYN】后,由于APP还是没有响应导致6秒后再次重传,重传后APP回复了【SYN,ACK】

    Web服务器侧抓包:
    APP 侧抓包只看到 JMeter 发的最后一条【SYN】消息,所以说明 CentOS 在底层就把
    【SYN】消息丢弃了,修改 tcp_max_syn_backlog 和 somaxconn 参数后,问题解决。

    展开全文
  • 快速的步骤概要编写你的脚本使用JMeter进行本地测试BlazeMeter沙箱测试使用一个控制台和一个引擎设置Users-per-Engine的数量设置并测试你的集合 (1个控制台和10-14 引擎)使用 Master / Slave 特性来达成你的最大CC...
  • 快速的步骤概要编写你的脚本使用JMeter进行本地测试BlazeMeter沙箱测试使用一个控制台和一个引擎设置Users-per-Engine的数量设置并测试你的集合(1个控制台和10-14 引擎)使用 Master / Slave 特性来达成你的最大CC...
  • 本文将从负载测试的角度,描述了做一次流畅的5万用户并发测试需要做的事情。 你可以在本文的结尾部分看到讨论的记录。 快速的步骤概要 编写你的脚本 使用JMeter进行本地测试 BlazeMeter沙箱测试 使用一个...
  • 快速的步骤概要编写你的脚本使用JMeter进行本地测试BlazeMeter沙箱测试使用一个控制台和一个引擎设置Users-per-Engine的数量设置并测试你的集合 (1个控制台和10-14 引擎)使用 Master / Slave 特性来达成你的最大CC...
  •  寻找拐点的意义就是当前并发用户下,系统的平均响应时间、TPS、报错率是否满足性能要求,如果满足,该并发用户就是满足用户需求下所能承受的最大并发用户数,在去考虑并发用户是否满足系统用户需求,可以结合系统...
  • 快速的步骤概要编写你的脚本使用JMeter进行本地测试BlazeMeter沙箱测试使用一个控制台和一个引擎设置Users-per-Engine的数量设置并测试你的集合 (1个控制台和10-14 引擎)使用 Master / Slave 特性来达成你的最大CC...
  • 快速的步骤概要编写你的脚本使用JMeter进行本地测试BlazeMeter沙箱测试使用一个控制台和一个引擎设置Users-per-Engine的数量设置并测试你的集合 (1个控制台和10-14 引擎)使用 Master / Slave 特性来达成你的最大CC...
  • 前天客户要求给他提供一份性能测试报告,说:“我们的系统将来的用户数量可以达到800人左右,所以我希望系统能够支持的最大用户并发数可以达到1000” 。⊙﹏⊙b汗我用的测试工具是Jmeter2.2。需要测试的是一个OA系统...
  • Apache JMeter

    2011-07-27 13:45:18
    当这些HTTP客户端请求被记录以后,测试运行时可以方便的设置重复次数和并发度(线程数)来产生巨大的流量。JMeter还提供可视化组件以及报表工具把量服务器在不同压力下的性能展现出来。  相比其他HTTP测试工具,...
  • 首先,我们添加好了一个测试计划后,主要是看线程组,如下图 压力测试就是要同时模拟多个用户同时对接口进行...如何知道接口最大的承载数量是多少,根据自己的测试计划,比如每次递增20个用户,同时访问,看看错误..
  • 本文将介绍运行5万并发用户测试所需要的步骤(该测试用户量最多可达200万)。...使用主从功能达到最大并发量目标。第1步:编写脚本在开始之前,请先从JMeter Apache社区网站(http://jmeter.apache.or...

空空如也

空空如也

1 2 3 4
收藏数 70
精华内容 28
关键字:

jmeter测试最大并发数量