跟老谭学java 8下载,t-io 和 Voovan 并发性能测试

前段时间写了有篇有关并发框架的文章《Netty、t-io、Voovan 框架浅谈》得到了大家不少的关注, 与此同时《Netty与Voovan并发性能对比》的留言中有位朋友希望将 Voovan 和 t-io 进行一个性能测试：

@spyv23提到希望我做一个 t-io 和 Voovan 的并发性能测试的比对,应这位朋友的要求我决定这次就来测一把。

有些同学可能也更好奇 Voovan 和 Netty 的性能对比可以参考《Netty与Voovan并发性能对比》这篇文章。

=============================2017-07-20 最新测试结果===========================

测试环境为发生任何变更依旧是那台陪我战斗过无数的 MacBook Pro.

主要优化了并发情况下的锁处理的机制,以及在服务端Accept 时的性能优化.

这次测试结果实在预热5次后的数据,可以对比6月28日测试结果中 5-10次的记录数据:

测试效果截图如下:

=============================2017-06-28 测试结果===========================

一、主机环境

首先老规矩说明一下测试的主机：

我的 MacBookPro， 测试时关闭的所有无关的其他软件。

二、测试方法描述：

场景选择： 模拟 HTTP 服务

为什么选择这种测试场景：

首先 HTTP 服务是大家比较常见的服务场景，其次基于 WEB 的性能测试工具也比较多，而且成熟，由测试工具对于测试结果带来的影响也相对较少。

为避免自己编码的压测工具带来各种风险,同时也为了使测试结果更加公平、真实、可信。测试方法如下:

1. 使用 ab (Apache bench)进行压力测试

2. Voovan 和 t-io 两个框架分别模拟 Http 服务,在接受到 HTTP 请求后不进行解析,直接返回相同的 Http 响应后关闭连接。

3. 每次响应都关闭连接，保证不会因 HTTP 的 KeepAlive 头带来的长连接影响测试结果的准确性。

三、测试代码

由于代码我都同步到了 Git@OSC，这里我就放上代码连接。

Tio:

Voovan:

启动服务命令并未增加任何参数调优,使用 java 启动时均使用的是 jvm 的默认参数设置。

四、测试脚本

ab -c 50 -n 2000 http://127.0.0.1:28080/test/ |grep "Requests per second"

在测试过程中发现对 t-io 调整参数到 -c 100的时候会出现这个问题

经过测试发现 Voovan 和 Netty 在调整参数到 -c 100都能够正常响应,所以最终将参数设定为-c 50

具体以原因并未深究,不知道在其他操作系统是否也会出现类似的问题。

五、结果分析

下面我们来看一下测试结果：

首先来一个线条图方便大家更直观的观察结果:

接下来我们来看看统计数据:

从上面的统计结果看经过15次,在第9次的时候 t-io 出现了一次 full GC 导致了较明显的 GC 停顿。

推测具体原因在之前的分析文章中提到过，极有可能是因为 Voovan 使用了对外内存有效的延缓了 full GC出现的时间，那么在有限的时间里总体来看减少了 full GC 的次数。

另外在性能上我们也看到 累计15次下来

Voovan 合计QPS 量为 9.0w

t-io 合计 QPS 量为7.3w.

统计15次测试结果后的数据平均下来:

Voovan 的 QPS 为: 6013,

t-io 的 QPS 量为 4925.

同时也考虑导去除 GC 导致的停顿的记录的统计结果，也就是去除第9次的结果后:

Voovan 的 QPS 为: 6132

t-io 的 QPS 量为 5270.

总的请求量为: 15*2000 = 30000

Voovan 累计用时: 11s

t-io 累计用时: 34s

去除 GC 导致的停顿的记录，也就是去除第9次的结果后，总请求量: 14*2000 = 28000

Voovan 累计用时: 11s

t-io 累计用时: 14s

六、内存使用情况对比

有很多个朋友更关注 Voovan 和 t-io 对内存使用的情况:

为了不等待第一次 GC 的发生,因为 GC 会严重干扰内存使用情况的评估，所以必须在一次 full gc 前取得数据，我们采用连续5次执行。

ab -c 50 -n 2000 http://127.0.0.1:28080/test/ |grep "Requests per second" 共计发起 1w 个请求

下面我们来通过 jvm-mon来观察堆内存的使用情况:

下图是 Voovan 的堆内存消耗情况:

下图是 t-io 的堆内存消耗情况:

可以看到:

Voovan 在响应1w 个请求后堆内存的消耗为12.7m,申请的最大堆内存为129m,为 jvm 默认分配的数值。

t-io在响应1w 个请求后堆内存的消耗为42.3m, 申请的最大堆内存为163.1m。说明曾经在运行过程突破过 jvm 阀值，JVM 增加了堆内存的分配到163.1m。

综合来看我认为 Voovan 在内存管理上相比较还是比较理想的。

=============================本次测试结果仅共各位参考===========================

多说一点点...点...点.....

由于 t-io 是长连接场景，所以可能优化的方向不同，导致了一个这样的测试结果。

下面附上一些我个人之前相关的性能测试文章：