• 运用MQTT-JMeter插件测试MQTT服务器性能


    转账地址:http://www.cnblogs.com/saryli/p/6928051.html
    如有侵权,请联系我删除,感谢作者的文章对我的帮助。

    今天我们介绍XMeter团队带来的新版MQTT-JMeter插件,您可以更为方便地添加MQTT连接、发布、订阅取样器,构造组合的应用场景,例如背景连接、多发少收、少发多收,计算消息转发时延等。利用该插件,我们为EMQ成功实施了包括百万级并发连接在内的一系列测试场景,这里有详细的测试报告。

    该插件发布在github,欢迎下载、使用并告诉我们您的意见建议。

    下面介绍一下插件的使用方法。

    安装

    从github下载您需要的release版本, 解压mqtt–xmeter-jar-with-dependencies.jar.zip, 将生成的jar文件放到JMeter安装主目录的lib/ext下,重启JMeter,就可以看到插件成功加载。

    这里写图片描述

    【注】推荐在最新的JMeter3.1或者3.0版本中安装使用本插件。

    连接操作取样器

    这里写图片描述

    • Server name or IP: 指向被测MQTT服务器地址。【注】为灵活起见,属性值都可以引用JMeter的系统或自定义变量。
    • Port number: 通常TCP连接的端口时1883, SSL连接则是8883。请参照服务器的具体配置。
    • Timeout(s): 连接超时设置,以秒为单位。
    • Protocols: 客户端与服务器通过SSL加密通道连接时,可以选择单向或者双向认证(Dual)。双向认证时,您还需要指定相应的信任秘钥库(Trust Key Store), 客户端证书,以及对应的文件保护密码(Secret)。这些文件可以通过服务器的证书配置转化得到。例如,对于EMQ的安装部署,/etc/cert下就存放了自签证的CA,服务器及客户端证书,参考下面的命令就可以生成插件所需的.jks, .p12文件,secret自行指定即可。
    • User authentication: 如果服务器配置了用户认证,您需要提供相应的用户名和口令。
    • ClientId prefix: 标识客户端的固定前缀,每个连接(虚拟用户)再添加一个uuid串,整个作为客户标识。
    • Keep alive(s): 心跳信号发送间隔。例如,300表示客户端每隔300秒向服务器发出ping请求,以保持连接活跃。
    • Connection keep time(s): 连接建立后,保持该连接的时长。例如,1800表示1800秒之后连接将被关闭,即使一直发送心跳信号。
    • Connect attempt max: 第一次连接过程中,尝试重连的最大次数。超过该次数则认为连接失败。
    • Reconnect attempt max: 后继连接过程中,尝试重连的最大次数。超过该次数则认为连接失败。

    发布操作取样器

    发布(Pub)取样器的连接相关属性与连接取样器完全相同,下面只介绍Pub特有的属性。

    这里写图片描述

    • QoS Level: 服务质量,取值为0,1,2,分别代表MQTT协议规范里的至多一次(AT_MOST_ONCE),至少一次(AT_LEAST_ONCE),精确一次(EXACTLY_ONCE)
    • Topic name: 发布消息所属的话题 (订阅方可以根据话题不同选择订阅)
    • Add timestamp in payload:如果勾选,发布的消息体开头会附带当前时间戳,利用它可以在消息接收端计算消息达到的延时。不勾选则只发送实际的消息体。
    • Message type: 目前支持三种消息类
    • String: 普通字符串 (如上面截图所示)
    • Hex String: 以16进制数值表示的串,比如字符串Hello,可以表示为48656C6C6F(其中,48在ascii表中对应字母H,依次类推)。通常16进制串用来构造非文本的消息体,例如描述某些私有的协议交互和控制信息等等。
    • Random string with fixed length: 按指定长度生成随机的串作为消息体。

    订阅操作取样器

    这里写图片描述

    • QoS Level: 服务质量,含义与发布操作取样器相同。
    • Topic name: 订阅消息所属的话题。
    • Payload includes timestamp: 如果勾选,会从消息体开头处解析发送时间戳,用于计算消息的接收延时。
    • Debug response: 如果勾选,消息内容会打印在JMeter的响应结果中,用于调试目的。正式运行测试建议不勾选。

    混合负载的测试场景

    运用以上3种MQTT取样器,结合JMeter灵活的测试控制,您可以制定各种类型的测试场景。下面我们举一个例子,构造一个混合负载的场景。

    这里写图片描述

    我们定义3个虚拟用户组,分别进行连接,发布,订阅操作。

    • 连接者:虚拟用户数=10, 发起10个到服务器的背景连接,每2秒钟发一次心跳请求,15秒后断连。
    • 发布者:虚拟用户数=5,每隔一秒发送一条32字节的随机串,带时间戳,循环10次结束。
    • 订阅者:虚拟用户数=2,接收相应话题上的消息,每隔一秒输出采样间隔里接收到的消息统计,循环10次结束。

    在JMeter中运行该场景,15秒钟左右运行结束。可以在测试结果树中看到每个操作的详细信息。表格视图的”Sample Time”列出了操作花费的时间(毫秒)。由于这次测试在本地,并发用户数很少,所以连接、消息发送、接收时延都很短。您可以指向实际的MQTT服务器,模拟更大的并发用户数。
    这里写图片描述

    结果树

    这里写图片描述

    结果列表

    在被测的EMQ服务器自己的度量仪表盘,我们可以看到连接、消息发送,接收等统计信息。

    【注】服务器的”received”, “sent”分别对应JMeter测试中的“发送者”和“订阅者”。

    这里写图片描述

  • 相关阅读:
    zabbix api
    cassandra学习笔记
    loki grafana
    logstash配置 filebeat配置
    k8s prometheus api
    51cto 先超Prometheus+Grafana监控告警系统实战
    51cto 张岩峰 Prometheus企业级监控系统:零基础入门
    imooc 使用Prometheus实践基于Spring Boot监控告警体系 笔记
    python3 django migrate
    python3虚拟环境
  • 原文地址:https://www.cnblogs.com/haitao130v/p/9664671.html
Copyright © 2020-2023  润新知