1.测试环境
测试过程中，网关服务器是基于4核8G，5M外网宽带的Linux服务器，Netty网关单点运行的情况下进行的。
|
硬件信息表 |
||
|
硬件名称 |
规格 |
用途 |
|
阿里云服务器 |
4核8G 5M带宽 |
Netty网关+Redis+RabbitMQ+测试Web（单点） |
|
实体机服务器 |
8核16G，内网 |
Netty网关+Redis+RabbitMQ+测试Web（单点） |
|
实体机服务器 |
8核16G，内网 |
压测工具部署 |
|
软件信息表 |
||
|
软件名称 |
版本 |
说明 |
|
JDK |
13 |
Netty运行Java环境 |
|
Redis |
3.2 |
Netty与测试Web与RabbitMQ公共资源存储 |
|
RabbitMQ |
3.5.7 |
消息中心（gps数据存储与平台交互） |
|
Ubuntu |
16.04 |
Linux网关服务器 |
|
Windows Server |
2008R2 |
Windows网关服务器 |
|
Windows |
7 |
内网环境压测工具部署 |
|
Windows Server |
2008R2 |
阿里云部署压测工具 |
2.测试结论
针对安装方面：Windows操作更加简单，不需要过高的技能要求，点击图标就可以进行安装。Linux环境相比Windows对安装部署人员要求就比较高，需要熟悉Linux操作系统命令以及对Linux系统性能优化比较熟悉的专业人员去安装部署。
功能测试方面：目前网关暂时只集成了对交通部808协议,所有的测试过程也是基于808协议的数据进行测试的，目前只是测试了gps数据的上传以及处理能力以及808之间的指令通讯方面的验证。
易用性测试方面：设备连接对应的IP与端口后即可完成设备与平台之间的通讯，使用比较简单。
兼容性测试方面：该网关支持Windows与Linux双系统，可以完美的跨平台使用。
性能测试方面：测试结果来看Linux操作系统下运行要比Windows下性能更好些。在Windows操作系统下，数据处理峰值为1580条/秒（因为Windows测试基于自己内部网络，不知道是不是网络限制还是Netty网关在Windows性能达不到要求，与Linux还是有很大差距的）。Linux操作系统下目前数据处理峰值单点可高达到3000条/秒。
稳定性测试方面：网关目前部署在我们公司阿里云服务器（4核8G，5M外网宽带）上，截止目前已经稳定运行9天；服务器内存，CPU状态良好占用内存600M~700M。如下所示：
以上结果满足我们对单点1万终端10s一条gps数据接入的期望，初步测试通过！
3.测试过程
3.1测试进度表
|
工作内容 |
开始时间 |
结束时间 |
输出内容 |
测试人员 |
|
内网测试环境部署（Windows+Liunx） |
2019-11-14 |
2019-11-14 |
Windows服务器下搭建网关 |
xxx |
|
内网压测工具部署 |
2019-11-15 |
2019-11-15 |
内网压测工具正常运行 |
xxx |
|
压测工具正常运行数据记录 |
2019-11-16 |
2019-11-25 |
输出压测工具测试截图 |
xxx |
|
外网测试环境Linux |
2019-11-14 |
2019-11-15 |
阿里云搭建好测试网关 |
xxx |
|
外网部署压测工具 |
2019-11-15 |
2019-11-16 |
阿里云搭建压测工具 |
xxx |
|
记录压测工具数据 |
2019-11-16 |
2019-11-25 |
输出压测工具测试截图 |
xxx |
3.2测试过程截图及说明
单个压测工具虚拟终端数及运行情况截图：
测试工具字段说明：
总连接数：虚拟的终端数量
成功连接次数：虚拟终端与Netty网关建立连接的次数
主动关闭数：压测工具由于网络问题导致的主动关闭的虚拟终端连接数（如果不为0，则表示测试环境网络异常，不满足测试要求）
被动关闭数：由于Netty网关的承载能力导致虚拟终端关闭的连接数（如果不为0则标识Netty网关所属服务器的网络存在异常或者Netty网关的承载能力已经处于或者临界承载能力的极限）
发送GPS总条数：虚拟出来终端向网关发送的GPS定位数据的总条数
测试环境开启的所有压测工具启动截图：
在外网环境下一共开启了5个压测工具，每个压测工具虚拟出2000个终端，一共1万个终端。（最多的时候开启了6个压测工具，虚拟出了1.2万个jt808协议的终端，由于测试环境网关限制，已经触及到了测试服务器网络带宽的瓶颈，保障测试可靠性，就开了一天，随后几天都是用1万台虚拟终端在进行测试）。
测试web截图1：
测试web截图2：
当前注册的终端为20000，10000接入的虚拟终端数，位置数据为接入的这一万台虚拟终端上次重置后到当前的总记录数（与压测工具发送的gps数据进行对比可以判断是否存在丢数据现象）。
压测性能参数参照交通部对部标平台压测的标准进行，使用的压测工具来自交通部《平台过检压力测试工具》
网关服务器内存，CPU使用情况截图：
其中包含两个Java项目进程，第一个（红框）为web测试平台的，可以忽略不计，第二个（绿框）为Netty网关的资源使用情况。
结合上面内容输出可以看出，当前服务器（4核8G）总的资源使用情况。
CPU：59.8%使用率（外部程序），18.0%（Linux内核），剩余17.3%，状态良好。
内存：剩余0.18G，程序占用：1.79G，数据交换缓冲区6.18G，内存比较危险，观察下方绿框内Netty内存使用情况为0.68G
所以一台Linux服务器，4核，8G，5M外网宽带的设备，是足够满足一台单点Netty网关运行。
下面是我加又加了2000台终端的截图：
网关也可以稳定运行。由于服务器资源（主要是测试工具运行环境与网关部署的环境带宽限制，已经达到了4M左右）限制，无法再继续增加虚拟设备。
3.3RabbitMQ相关截图说明
如果服务器网络带宽足够，测试环境网络也还OK的情况下，我都想试试2万台的接入看看并发能否达到5000/s。
以上报告是公司内部测试工程师交付给我的第一轮整体测试说明，后面在进行源码整合与优化后，又进行了很多次的测试，整个测过程试持续了一个多月，节前又进行了对应用平台的架构整改，让平台能够有个更加友好的交互。现在总算有点时间，把近几个月的成果展示一下。