共计 4502 个字符,预计需要花费 12 分钟才能阅读完成。
<img width=”100%” src=”https://www.dgiotcloud.cn/wp-content/uploads/2022081106113842.png” >
[小 迪 导读]:在软件运行时,设施一直减少,软件内信息量一直晋升,程序压力一直减少,程序的承受能力至关重要。
dgiot 计划 | 其余计划 |
---|---|
利用 ZETAAP 影子设施模仿 1 万 ZETAAP、千万 ZETATAG 同时在应用程序中工作 | 我的项目实际测试软件承受能力 |
1 概述
1.1 测试背景
随着 ZETA 产业的倒退与业务的深入利用,设施治理、网络管理、应用服务都面临大规模设施接入挑战。ZETA 设施接入服务必须可能反对高并发性 (如超过百万级的并发设施接入)、高速率 (如每秒超过十万事件)、高吞吐量 (如每 100 秒解决超过 GB)。同时,利用事件发生率各不相同,须要接入服务有超强的解决能力,保障利用事件的失常解析。
1.2 测试简介
压力测试是软件质量保证的一项根本行为,是每个重要软件测试工作的一部分。软件压力测试是指对系统一直施加压力的状况下,依据零碎各项指标的变动状况来判断:1、零碎可能存在的瓶颈;2、零碎负载能力;3、零碎失常运行状况下的运行效率。
<img width=”100%” src=”https://www.dgiotcloud.cn/wp-content/uploads/2022081104381249.png” >
图 1 - 理论业务场景
本次压力测试通过模仿 1 万 ZETA AP、千万 ZETA TAG 标签的在线运行,精准高效实现 ZETA AP、ZETA TAG 的在线协定解析、解析数据实时入库、海量数据在线查问与展现等流程。同时,对实在物流业务场景进行形象,实现批次 ZETA TAG 在不同线路上产生轨迹扭转,挪动过程中利用不同的 ZETA AP 实现定位。ZETA TAG 在线运行过程中,每隔 15 分钟发送心跳包,被邻近的单个或者多个 ZETA AP 报送至服务端。服务端会依照策略抉择信号最好的上报数进行存库,并利用上报信号最好的 AP 对 ZETA TAG 进行定位。
1.3 目标
通过压力测试,判断以后应用环境状况下零碎的负载能力,为今后利用范畴扩充,用户量回升后,服务器扩容、降级等提供必要的技术撑持,及服务器布局等。
本次测试目标是为了验证基于 dgiot 连贯与设施治理平台的 ZETA 物流跟踪治理可能实现千万级 ZETA TAG 标签同时在线稳固运行、数据及时回传、失常入库、高效查库。
本次测试场景的压力与复杂度远高于实在场景,在保障 ZETA 物流跟踪以后业务能够失常发展的同时,也能够无效撑持 ZETA 相干业务利用的拓展与深入利用。
2 测试环境
2.1 网络
为了尽量避免网络传输给测试后果带来的影响,应该选取外部局域网作为压力测试的网络环境(然而咱们没有专门的局域网,只能用外网测试)。网络框图如下:
图 2 - 网络结构示意图
2.2 腾讯云服务器
平台服务器即连贯与设施治理平台服务器,是压力测试的次要对象。平台服务器为目前正式环境中运行的服务器,应用服务器配置不同,其压力测试后果也不统一。
服务器配置如下:
服务器类型 | 腾讯云服务器 |
---|---|
处理器 | 16 外围 CPU 2.0GHz |
内存 | 32G |
硬盘 | 500G |
操作系统 | LINUX centos7.3 64 位 |
2.3 应用服务器
服务器配置如下:
服务器类型 | 腾讯云服务器 |
---|---|
处理器 | 2 外围 CPU 2.0GHz |
内存 | 4G |
硬盘 | 50G |
操作系统 | LINUX centos7.3 64 位 |
2.4 测试机
因为压力测试是对系统负载能力的测试,无奈通过真是的环境来进行获取相干指标,因而通过测试机与测试服务,模仿 1 万 AP、千万 ZETATAG 与服务器高频数据交互,利用算法虚构实在业务场景下理论的操作来进行测试。
测试机部署虚构云设施服务,及进行压力测试的客户端机器,个别采纳高配置的机器来进行测试。
在压力测试过程中,个别疏忽测试机对压力测试后果的影响。
测试机配置 (腾讯云服务器):
服务器类型 | 腾讯云服务器 |
---|---|
处理器 | 4 外围 CPU 2.0GHz |
内存 | 8G |
硬盘 | 200G |
操作系统 | LINUX centos7.3 64 位 |
2.5 条件与限度
为了尽量保障压力测试后果的真实性,在压力测试期间,做如下的条件限度:
1、尽量在局域网内进行压力测试,防止因网络起因干扰测试后果与论断;
2、数据库服务器除了解决测试利用零碎申请外,不进行其它简单利用申请;
3、测试应用服务器不进行其它的失常业务解决,因而压力测试安顿在非工作日进行;
4、压力测试后果疏忽测试机、应用服务器、网络等其它额定的开销,不作为零碎瓶颈的剖析对象。
2.6 测试场景
启动测试机,导入已编写好的服务,设置线路条数、起始地位、发送频率、AP 数量、TAG 取值范畴、等参数信息,便能够启动模仿场景,进行 AP、TAG 与服务器的高频数据交互。
3 测试工具
3.1 测试工具
测试工具:虚构 AP;监控工具:Grafana
3.2 工具简介
利用 ZETAAP 影子设施模仿 1 万 ZETAAP、千万 ZETATAG 同时在应用程序中工作的环境,对应用程序进行负载测试。当应用程序在负载状态下运行时,Grafana 会精确评测、监控并剖析零碎的性能和性能。
ZETAAP 影子设施应用 TCP/IP 协定,次要思维是应用虚构设施来模仿实在设施并发对系统施加压力。通过 ZETAAP 影子设施模仿接管 ZETATAG 标签上报数据,将上报数据上报至服务端。
4 测试场景与指标
ZETAAP、ZETATAG 设施音讯收发是平台功能模块中实现数据网关性能,同时服务器须要进行简单运算的查问、计算。但也是零碎中根本的模块,操作量绝对较大,性能的要求较高,对服务的压力绝对较大。
<img width=”100%” src=”https://www.dgiotcloud.cn/wp-content/uploads/202208110439313.png” >
ZETA 物流跟踪业务场景图
ZETA 设施运行模仿:
ZETA AP:每 10s 被动连贯服务端,间断 30min 未连上期待 2min 再次 连贯;
连贯状态下 1min 一次心跳交互;
间断三次未收到 ACK,发动重连。
ZETA TAG:每 15 分钟上报一次心跳包;
心跳报文被不同 AP 接管上报后,服务端会比拟后保留首次
收到 TAG 心跳后 3s 内 RSSI 最强上报的 AP 地位信息作为 TAG 的以后地位。
客户端场景模仿形容:
运输、配送线路:本次场景模仿线路总计 200 条,线路能够配置。
运输车辆:本次场景模仿运输车辆 50000 部,货车会模仿实在物流场景在既定线路上进行挪动,车上 ZETAG 标签随之挪动。
ZETA AP:本次模仿 10000 台,每条线路上散布 500 台 ZETAAP
ZETA TAG 数量:本次模仿在运 ZETAG1000 万个,ZETAG 随运输车辆挪动,每隔 15 分钟的心跳报文被相邻的 2 - 3 个 ZETAAP 接管。
服务端业务形容:
1、每 15 分钟内实现千万在运 ZETAG 标签心跳数据包解析(加上冗余报文,每 15 分钟内解析心跳报文数量 2000 多万条);
2、实现 ZETA TAG 心跳数据比拟与冗余数据过滤;
3、实现解析出的海量 TAG 地位信息实时分类入库;
4、反对 ZETATAG 最新地位更新与轨迹查问;
5、每分钟实现 1 万 ZETAAP 的心跳报文解析、存储;
6、实现 ZETAAP 运行状态信息的接管与存储;
7、反对 ZETA AP 运行状态信息查问。
依据测试零碎中音讯的业务场景状况,选取以下指标作为场景压力测试状况判断根据:
A、ZETA AP 在线状况统计
B、ZETA AP 在线率
C、在线 ZETAG 标签数量
D、ZETA 标签解析包数量
E、1/5/15 分钟 CPU 均匀负载
F、内存使用量
5 测试策略
5.1 测试筹备
依照本测试计划及测试计划,筹备测试数据,实现服务部署,并在模仿环境中进行测试运行。
5.2 压力测试
压力测试分以下几种状况测试:
测试内容 | 测试项阐明 |
---|---|
A、ZETA AP 在线状况统计 | 统计同时在线的 ZETAAP 数量 |
B、ZETA AP 在线率 | 在线 ZETAAP 与模仿总量的比值 |
C、在线 ZETAG 标签数量 | 统计心跳周期内 ZETAG 在线数量 |
D、ZETA 标签解析包数量 | 平台实现的 ZETA 标签解析数量 |
E、1/5/15 分钟 CPU 均匀负载 | 平台服务器的 CPU 负载信息 |
F、内存使用量 | 平台服务器的内存使用量 |
压力测试过程中须要记录的性能指标包含:
测试环境 | 指标 |
---|---|
平台指标 | 最大 AP 在线数 ZETAG 标签并发数 最小响应工夫 最大响应工夫 均匀响应工夫 |
被测服务器 CPU | 最小 均匀 最大 |
被测服务器内存耗费 | 最小值 最大值 平均值 |
6 测试后果
6.1 测试后果数据与剖析图表
ZETAG 标签数据包入库总量(入库超 10 亿条):
ZETA AP 在线数量:
ZETAG 标签在线数量统计(15 分钟最高超过 1856 万):
ZETAG 标签解析数量:(两小时内约解析 1.5 亿条)
1/5/15 分钟 CPU 负载统计:(负载比拟安稳)
内存使用量:(客户端最高 7.19G,服务端最高 29.6G)
磁盘读写测试:
API 压力测试后果:
ZetaEtag 接口
超时工夫为 5 秒
随机读 tag,数据库内数据 58169933 条
tag 生成形式:FF 结尾后六位随机生成
申请次数 / 次 | 200000 |
---|---|
测试总工夫 / 秒 | 269.583 |
返回 200 数 | 120116 / 200000 |
返回 404 数 | 79884 / 200000 |
返回其余状态码 | 0 / 200000 |
返回成功率 / % | 100 |
每秒申请数 / 次 / 秒 | 741.88 |
* 返回 status code 为 200(找到指标 tag)或 404(找不到指标 tag)两者都视为调用胜利
服务器 CPU 负载
服务器内存负载
ZetaEtagHistory 接口
超时工夫为 5 秒
对所有 tag 随机读,limit 值为 100,日期范畴在正当范畴内随机产生,数据库内数据 58169933 条
tag 生成形式:FF 结尾后六位随机生成
日期生成形式:1569558137~1569579737 间随机数
申请次数 / 次 | 200000 |
---|---|
测试总工夫 / 秒 | 298.123 |
返回 200 数 | 200000 / 200000 |
返回其余状态码 | 0 / 200000 |
返回成功率 / % | 100 |
每秒申请数 / 次 / 秒 | 670.86 |
服务器 CPU 负载
服务器内存负载
6.2 测试后果剖析
依据以上测试后果可得出以下论断:
测试内容 | 测试后果(取值范畴) |
---|---|
A、ZETA AP 在线状况统计 | 9960-20000 |
B、ZETA AP 在线率 | 100% |
C、在线 ZETAG 标签数量 | 最大值:18562926 |
D、ZETA 标签解析包数量 | 共计:1010505054 |
E、1/5/15 分钟 CPU 均匀负载 | 1 分钟:0.11-15.85 分钟:0.78-13.915 分钟:5.8-11.65 |
F、内存使用量 | 服务端:12.46G(均匀)客户端:2.90G(均匀) |
经剖析能够得出以下论断:
1、15 分钟内超过千万个(1020 万)的 TAG 标签实现了心跳数据包上报、解析、存储;
2、服务运行稳固,内存使用量与 CPU 负载均在安稳状态;
以后存在问题
综上所述,平台能够稳固撑持千万级 ZETA TAG 同时在运的物流跟踪网络经营与业务利用。通过优化策略与扩容能够撑持更大规模、更多畛域的 ZETA 利用。
[小 迪 点评]
- dgiot 测试场景的压力与复杂度远高于实在场景,保障 ZETA 物流跟踪以后业务能够失常发展。
- dgiot 压力测试还能无效撑持 ZETA 相干业务利用的拓展与深入利用。
想理解更多 dgiot 的具体细节,欢送大家在 GitHub 上查看相干源代码。