八种 WebSocket 框架的性能比较

点击上方“芋道源码”，选择“置顶公众号”

技术文章第一时间送达！

源码精品专栏

 

• 精尽 Dubbo 原理与源码 69 篇

• 精尽 Netty 原理与源码 61 篇

• 中文详细注释的开源项目
  

• Java 并发源码合集

• RocketMQ 源码合集

• Sharding-JDBC 源码解析合集

• Spring MVC 和 Security 源码合集
  

• MyCAT 源码解析合集

来源：http://t.cn/R94WxA1

---

---

前一篇文章使用四种框架分别实现百万websocket常连接的服务器介绍了四种websocket框架的测试方法和基本数据。 最近我又使用几个框架实现了websocket push服务器的原型，并专门对这七种实现做了测试。 本文记录了测试结果和一些对结果的分析。
这七种框架是：

• Netty

• Undertow

• Jetty

• Vert.x

• Grizzly

• spray-websocket

• nodejs-websocket/Node.js

最近用Golang实现了第八种，Go表现还不错。

• Go

1. 测试环境

使用三台C3.4xlarge AWS服务器做测试。 一台作为服务器，两台作为客户端机器， 每台客户端机器启动10个client,一共20个client
C3.4xlarge的配置如下：

型号	vCPU	内存 (GiB)	SSD 存储 (GB)
c3.large	2	3.75	2 x 16
c3.xlarge	4	7.5	2 x 40
c3.2xlarge	8	15	2 x 80
c3.4xlarge	16	30	2 x 160
c3.8xlarge	32	60	2 x 320

服务器和客户端机器按照上一篇文章做了基本的优化。

以下是测试的配置数据：

• 20 clients

• setup rate设为500 * 20 requests/second = 10000 request /second

• 每个client负责建立50000个websocket 连接

• 等1,000,000个websocket建好好，发送一个消息(时间戳)给所有的客户端，客户端根据时间戳计算latency

• 如果服务器setup rate建立很慢，主动停止测试

• 监控三个阶段的性能指标： setup时， setup完成后应用发呆(idle)时，发送消息时

2. 测试结果

2.1 Netty

Setup时

• cpu idle: 90%

• minor gc: Few

• full gc: No

Setup完成， 应用Idle时

• cpu idle: 100%

• memory usage: 1.68G

• server free memory: 16.3G

发送消息时

• cpu idle: 75%

• minor gc: few

• full gc: No

• Message latency (one client)

       count = 50000
         min = 0
         max = 18301
        mean = 2446.09
      stddev = 3082.11
      median = 1214.00
        75% <= 3625.00
        95% <= 8855.00
        98% <= 12069.00
        99% <= 13274.00
      99.9% <= 18301.00
  

2.2 Vert.x

Setup时

• cpu idle: 95%

• minor gc: Few

• full gc: No

Setup完成， 应用Idle时

• cpu idle: 100%

• memory usage: 6.37G

• server free memory: 16.3G

发送消息时

• cpu idle: 47% ~ 76%

• minor gc: few

• full gc: few

• Message latency (one client)

       count = 50000
         min = 49
         max = 18949
        mean = 10427.00
      stddev = 5182.72
      median = 10856.00
        75% <= 14934.00
        95% <= 17949.00
        98% <= 18458.00
        99% <= 18658.00
      99.9% <= 18949.00
  

2.3 Undertow

Setup时

• cpu idle: 90%

• minor gc: Few

• full gc: No

Setup完成， 应用Idle时

• cpu idle: 100%

• memory usage: 4.02G

• server free memory: 14.2G

发送消息时

• cpu idle: 65%

• minor gc: few

• full gc: No

• Message latency

       count = 50000
         min = 1
         max = 11948
        mean = 1366.86
      stddev = 2007.77
      median = 412.00
        75% <= 2021.00
        95% <= 5838.00
        98% <= 7222.00
        99% <= 8051.00
      99.9% <= 11948.00
  

2.4 Jetty

Setup时

• cpu idle: 2%

• minor gc: Many

• full gc: No

• memory usage: 5G

• server free memory: 17.2G

当建立360,000左右的websocket时， setup非常的慢， gc频繁，无法继续正常建立websocket， 主动终止测试。

2.5 Grizzly

Setup时

• cpu idle: 20%

• minor gc: Some

• full gc: Some

• memory usage: 11.5G

• server free memory: 12.3G

当建立500,000左右的websocket时， setup非常的慢， gc频繁，无法继续正常建立websocket， 主动终止测试。

2.6 Spray

Setup时

• cpu idle: 80%

• minor gc: Many

• full gc: No

当建立500,000左右的websocket时， setup非常的慢， gc频繁，无法继续正常建立websocket， 主动终止测试。

2.7 Node.js

Setup时

• cpu idle: 94%

Setup完成， 应用Idle时

• cpu idle: 100%

• memory usage: 5.0G

• server free memory: 16.3G

发送消息时

• cpu idle: 94%

• Message latency (one client)

• Message latency

       count = 50000
         min = 0
         max = 18
        mean = 1.27
      stddev = 3.08
      median = 1.00
        75% <= 1.00
        95% <= 1.00
        98% <= 1.00
        99% <= 1.00
      99.9% <= 15.00
  

2.8 Go

Setup时

• cpu idle: 94%

Setup完成， 应用Idle时

• cpu idle: 100%

• memory usage: 15G

• server free memory: 6G

发送消息时

• cpu idle: 94%

• Message latency (one client)

• Message latency

       count = 50000
         min = 0
         max = 35
        mean = 1.89
      stddev = 1.83
      median = 1.00
        75% <= 1.00
        95% <= 2.00
        98% <= 2.00
        99% <= 4.00
      99.9% <= 34.00
  

3. 测试结果分析

• Netty, Go, Node.js, Undertow, Vert.x都能正常建立百万连接。 Jetty, Grizzly 和 Spray未能完成百万连接

• Netty表现最好。内存占用非常的少， CPU使用率也不高。 尤其内存占用，远远小于其它框架

• Jetty, Grizzly和Spray会产生大量的中间对象，导致垃圾回收频繁。Jetty表现最差

• Node.js表现非常好。 尤其是测试中使用单实例单线程，建立速度非常快，消息的latency也很好。 内存占用也不错

• Undertow表现也不错，内存占用比Netty高一些，其它差不多

• 这里还未测到Spray另一个不好的地方。 在大量连接的情况小，即使没有消息发送，Spray也会占用40% CPU 时间

---

---

欢迎加入我的知识星球，一起探讨架构，交流源码。加入方式，长按下方二维码噢：

已在知识星球更新源码解析如下：

• 《精尽 Dubbo 源码解析系列》69 篇。

• 《精尽 Netty 源码解析系列》61 篇。

• 《精尽 Spring 源码解析系列》35 篇。

• 《精尽 MyBatis 源码解析系列》34 篇。

• 《数据库实体设计》17 篇。

• 正在准备更新《精尽 Spring MVC 源码解析系列》

目前在知识星球更新了《Dubbo 源码解析》目录如下：

01. 调试环境搭建
02. 项目结构一览
03. 配置 Configuration
04. 核心流程一览

05. 拓展机制 SPI

06. 线程池

07. 服务暴露 Export

08. 服务引用 Refer

09. 注册中心 Registry

10. 动态编译 Compile

11. 动态代理 Proxy

12. 服务调用 Invoke

13. 调用特性 

14. 过滤器 Filter

15. NIO 服务器

16. P2P 服务器

17. HTTP 服务器

18. 序列化 Serialization

19. 集群容错 Cluster

20. 优雅停机

21. 日志适配

22. 状态检查

23. 监控中心 Monitor

24. 管理中心 Admin

25. 运维命令 QOS

26. 链路追踪 Tracing

... 一共 69+ 篇

目前在知识星球更新了《Netty 源码解析》目录如下：

01. 调试环境搭建
02. NIO 基础
03. Netty 简介
04. 启动 Bootstrap

05. 事件轮询 EventLoop

06. 通道管道 ChannelPipeline

07. 通道 Channel

08. 字节缓冲区 ByteBuf

09. 通道处理器 ChannelHandler

10. 编解码 Codec

11. 工具类 Util

... 一共 61+ 篇

目前在知识星球更新了《数据库实体设计》目录如下：

01. 商品模块
02. 交易模块
03. 营销模块
04. 公用模块

... 一共 17+ 篇

目前在知识星球更新了《Spring 源码解析》目录如下：

01. 调试环境搭建
02. IoC Resource 定位
03. IoC BeanDefinition 载入

04. IoC BeanDefinition 注册

05. IoC Bean 获取

06. IoC Bean 生命周期

... 一共 35+ 篇

目前在知识星球更新了《MyBatis 源码解析》目录如下：

01. 调试环境搭建
02. 项目结构一览
03. MyBatis 面试题合集

04. MyBatis 学习资料合集

05. MyBatis 初始化

06. SQL 初始化

07. SQL 执行

08. 插件体系

09. Spring 集成

... 一共 34+ 篇

源码不易↓↓↓↓↓

点赞支持老艿艿↓↓