一种WEBSOCKET的性能测试工具设计模型

胡通

（中移（杭州）信息技术有限公司 浙江省杭州市 311121）

1 引言

随着移动互联网、5G 的飞速发展，高性能高并发的即时通信，有着非常广泛的应用场景，例如大家所熟知的微信聊天、大规模消息推送、视频会议、直播弹幕、智能家居等，总之，一切高实时性要求的通讯场景，都需要高并发的即时通信。

中国移动未来所有接入物联网的智能家庭宽带设备，都将是即时通信系统的客户端，这就意味着推送服务未来会面临海量的设备和终端接入。为了支持这些千万级、亿级终端，一定是需要强悍的后台系统，而为了验证该后台系统是否能支撑起如此庞大的家庭宽带设备，需要进行系统的性能测试，也就需要一种方法可以模拟这些百万、千万、亿级的设备终端软件测试工具。

目前，即时通信应用大部分是基于WEBSOCKET 协议进行开发，而现有的主流性能测试工具(如LOADRUNNER、JMETER 等软件)，一方面对该协议支持的粒度不够，无法满足私有化的交互协议要求，另一方面由于其工具本身采用多线程的模式，模拟百万连接的资源消耗巨大，甚至无法胜任，因此，测试人员无法高效率地开展WEBSOCKET 协议类的性能测试。

如何针对基于WEBSOCKET 协议的即时通信应用实施性能测试成为了软件测试研究领域中亟待解决的问题，在这个问题的研究上既存在着机遇又充满着挑战。

基于以上研究讨论，本文采用互联网行业中一些高性能的框架和中间件，设计了一种WEBSOCKET 协议的性能测试工具模型，以弥补此类工具的空白。该方法主要借助于NETTY 的异步、事件驱动的特性构建高性能的客户端性能测试工具，首先，通过自定义协议的编解码，可以方便的实现移动家宽宽带设备协议数据的编码和解码，可扩展性强；另外，优化改造池化技术，重用连接，防止反复申请和释放连接，提高连接的使用率和消息的收发能力；然后引入KAFKA 和REDIS 中间件，进行性能指标数据的汇总统计；最后通过测试节点的自动调度，灵活增加客户端的并发能力，满足更大规模场景的WEBSOCKET的性能测试需求。

2 WEBSOCKET性能要点

2.1 WEBSOCKET特性

WEBSOCKET 是一个独立的基于TCP 的协议，是HTML5 新出的一个协议，与HTTP 协议具有一定的交集。在WEBSOCKET出现之前，网站为了实现即时的通信，都是采用轮询拉取服务端的数据，虽然这种方式可以完成类似于数据推送的通信，但是在即时性和性能上都不如WEBSOCKET 技术。

WEBSOCKET 在建立连接后允许客户端和服务器之间进行全双工通信，以便任一方都可以通过建立的连接将数据推送到另一端。WEBSOCKET 只需要建立一次连接，就可以一直保持连接状态，这相比于轮询方式的不停建立连接显然效率要大大提高。

因此，WEBSOCKET 协议具有显著的2 点特性：

图1：总体设计图

图2：自定义消息

2.1.1 支持推送功能

支持服务器端向客户端推送功能，服务器可以直接发送数据而不用等待客户端的请求，实时性强。

2.1.2 减少通信量

只要建立起WEBSOCKET 连接，就一直保持连接，在此期间可以源源不断地传送消息，直到关闭请求，相比于HTTP，不但每次连接时的总开销减少了，而且WEBSOCKET 的首部信息量也更小，通信的效率更高。

2.2 WEBSOCKET性能点

由于WEBSOCKET 连接与典型的HTTP 连接请求方式不同，因此其性能测试中关注的性能点也不一样，结合日常的系统项目工程的应用实践，重点提炼了3 个性能点。

WEBSOCKET 性能测试的关注点：

（1）系统可以瞬间创建长连接的数目；

（2）系统可以长时间支撑的长连接数目；

（3）系统在保持一定的连接数下推送数据的速度。

与此相应的，可以设计3 种典型的性能测试场景：

场景1:大量连接的创建，即不断模拟大量用户对被测系统WEBSOCKET 连接的创建过程。

场景2：长时间稳定保持大量连接，即按照一定速度创建连接，并通过心跳消息保持连接长时间的处于连接状态。

场景3：大量推送消息，即通过保持一定数目的长连接，然后在各个连接通道上不断触发消息推送。

3 性能测试工具设计模型

3.1 总体设计框架

NETTY 是一款异步的事件驱动的网络应用开源框架，用于快速开发可维护的高性能、高扩展性协议服务器和客户端。通常该框架应用于服务端的开发，而本文充分借助于该框架的高性能的能力设计了一个典型客户端工具，应用于WEBSOCKET 协议的性能测试。

该性能测试工具设计模型核心主要包括测试分布式调度、压测节点、数据采集3 个模块，如图1所示。首先，测试分布式调度会根据测试任务规模级别信息自动选择可用的节点机器发起分布式的测试任务，然后压测节点借助于NETTY 的自定义编解码方式，完成私有协议的数据解析；之后通过优化配置池化和共享技术提升客户端的建立连接的能力；最后数据采集通过REDIS 和KAFKA 中间件存储统计器计算出连接数、发包速度、收包速度、丢包率等性能指标。

3.2 分布式调度

若要模拟百万千万的大规模的性能测试要求，可以根据压测节点机器的配置或资源结合一定的算法自动分配不同压测节点的压测任务大小，然后再采用分布式的方式发起压力。通过该方式，可以最大限度的发挥不同压测节点的资源，提高压力产生的能力，满足大规模需求。

3.3 压测节点

3.3.1 压力产生器

压力产生器采用SPRINGBOOT 技术作为服务框架，基于高性能网络框架NETTY 进行构建，与NETTY 提供的线程模型进行紧密结合。

基于NETTY 线程模型改造执行线程池，任务执行线程池维护一个多路复用的线程池，每个线程对应多个连接，对应NETTY框架中每个线程对应多个CHANNEL，另外任务执行线程池中还包括一个连接池，该连接池为基于线程池创建的CHANNEL 连接池，在初始化阶段，为每个线程创建多个CHANNEL，并且这些CHANNEL 是可以复用的，当一个实例被提交给一个线程时，该线程为该实例分配一个可用的连接供使用。每个实例执行时是非阻塞的，所以即使是单线程也可以达到较高的并发量。

通过优化改造NIO 异步多线程模型，设定同一个EVENTLOOP会被多个CHANNEL 所共享，这使得可以通过尽可能少量的THREAD 来支撑大量的CHANNEL，而不是每个CHANNEL 分配一个THREAD，并结合多路复用器SECLTOR，使得少量资源即可模拟成千上万的移动家宽宽设备客户端。

3.3.2 自定义消息

移动家庭宽带设备采用自定义的WEBSOCKET 的协议进行设备的登陆和数据的上报，如图2所示，采用5 个字节的消息头和不定长的消息体，其中消息头包括开始标志、消息类型和消息长度，消息长度代表消息体的大小。

本文采用NETTY 的自定义编解码器，可以方便灵活的完成协议数据的交互，根据协议规定要求添加一个CHANNELHANDLER的编码器和解码器即可进行消息的处理。

主要是通过NETTY 提供的LengthFieldPrepender 编码器，自动计算当前待发送数据的长度，并将该长度添加到当前数据的头部形成待发送的完整数据桢。在接收数据的时候，使用的是LengthFieldBasedFrameDecoder 解码器，通过该解码器首先根据开始标志和5 字节长度自动截取数据头，并解析出消息类型和消息长度，然后依据该消息长度在此后截取消息体部分的字节流，解决数据传输过程中出现粘包问题,完成数据解码,保证数据的正确性和安全性，最后再交给专门的事务处理器HANDLER 进行处理和响应。

3.4 性能数据采集

WEBSOCKET 长连接的性能指标数据不同于常见的HTTP 请求，性能关注点侧重于连接数、收包速度、发包速度、丢包率等。另外，传统的同步服务调用，发起服务调用之后，业务线程阻塞，等待响应，接收响应之后，业务线程继续执行，对发送的消息进行累加，获取性能指标数据；而使用NETTY，所有的网络I/O 操作都是异步执行的，不能和同步执行一样计算性能指标。

本文借助于REDIS 的原子性操作，汇总统计压测节点建立的WEBSOCKET 连接个数，避免脏写。另外通过使用KAFKA 作为消息队列来收集WEBSOCKET 长连接收发的性能消息数据，可以降低系统之间的耦合度。KAFKA 消息队列方式可以控制消息消费者消费的速度，可以提高消息处理效率并避免由于消费速度过慢导致消息堆积或消费速度过快导致长时间等待的情况。

另外，如果压测节点存在多个共同参与施压，则可以建立多个KAFKA 消息队列，依次存放每个执行节点单独上报和接收的数据，之后再进行汇聚计算。

通过这个方式可以便捷地获取压测过程中的长连接性能指标，观察被测系统的稳定性和状态。

4 结束语

本文主要设计思路借鉴了很多开源框架的高性能设计原则，始终本着使用简单，低耦合和高内聚的软件设计思路进行实现，采用的都是通用插件式设计，方便后续扩展。

该性能测试工具设计模型通过优化的池化和重用线程方式来消除由上下文切换所带来的开销，能够适应快速增长的移动设备的规模，可以在保持服务资源低成本的同时，模拟更大量的家庭宽带设备，伸缩能力强。

并且，利用NETTY 自定义编解码器，能够高效地完成移动家庭宽带设备的WEBSOCKET 协议的自定义数据交互，灵活性高。

最后，结合高性能中间件REDIS 和KAFKA，采集、统计分析出WEBSOCKET 长连接的连接数、发包速度、收包速度等特殊的性能指标，弥补了WEBSOCKET 长连接协议无法有效开展性能测试的技术空白，丰富了性能测试手段和方式。