《Dubbo 实现原理与源码解析 —— 精品合集》 《Netty 实现原理与源码解析 —— 精品合集》
《Spring 实现原理与源码解析 —— 精品合集》 《MyBatis 实现原理与源码解析 —— 精品合集》
《Spring MVC 实现原理与源码解析 —— 精品合集》 《数据库实体设计合集》

摘要: 原创出处 https://colobu.com/2015/07/14/performance-comparison-of-7-websocket-frameworks/ 「colobu」欢迎转载,保留摘要,谢谢!


🙂🙂🙂关注**微信公众号:【芋道源码】**有福利:

  1. RocketMQ / MyCAT / Sharding-JDBC 所有源码分析文章列表
  2. RocketMQ / MyCAT / Sharding-JDBC 中文注释源码 GitHub 地址
  3. 您对于源码的疑问每条留言将得到认真回复。甚至不知道如何读源码也可以请教噢
  4. 新的源码解析文章实时收到通知。每周更新一篇左右
  5. 认真的源码交流微信群。

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

最近用Golang实现了第八种,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 时间
文章目录
  1. 1. 1. 测试环境
  2. 2. 2. 测试结果
    1. 2.1. 2.1 Netty
    2. 2.2. 2.2 Vert.x
    3. 2.3. 2.3 Undertow
    4. 2.4. 2.4 Jetty
    5. 2.5. 2.5 Grizzly
    6. 2.6. 2.6 Spray
    7. 2.7. 2.7 Node.js
    8. 2.8. 2.8 Go
  3. 3. 3. 测试结果分析