FinTrade性能测试报告
-
测试目的
本报告为FinoTrade产品交易总线的压力测试报告,其目的在于统计在不同的测试场景下总线的压测情况,指标包含吞吐量和时延,并根据压测结果判断当前总线性能是否已达到最优。
测试环境
测试案例
测试覆盖
-
消息协议:FIX、Protobuf、Binary(java暂不支持)
-
API:FinoTrade API(Go)、FinoTrade API(Java)
-
测试环境:docker host模式、docker bridge模式、物理机
测试方案
-
测试案例简述:启动两个不同的进程,一个进行用于pub、一个进程用于sub
-
测试前提:pub、broker、sub在同一台机器
消息大小:
测试步骤:
-
给定需pub的msg总数(N)及每轮需pub的msg数(n,亦为batch)。
-
publisher不断pub msg,但每pub n个msg便等待一定的时间(此时间不变,用于控制吞吐,通过改变n值,改变吞吐),待pub最后一条msg后等待一段时间(几秒钟即可)再关闭pub的进程。
- subcriber不断sub msg,message(Go)从header中获取msg的sub和pub时间并存储起来,待接收完所有msg后统计出平均时延、pub及sub的吞吐量;message(Java)在pub和sub端通过System.nanotime()获得时间,并存储在文件中,待sub完所有数据后再进行数据分析。
通过改变n的值,执行步骤b和c,统计数据并分析吞吐与时延的关系。
预期结果:不断增加n,在某一段内,吞吐与时延的关系呈线性增长,达到某一点,增长斜率突然增加。此时该点即为最优值。
注:
-
该测试方案需覆盖消息协议、API及测试环境的多种场景组合。
-
步骤b中等待的时间需保证,每轮只pub一个消息的情况下不会产生消息的堆积,通过多次实验,此次测试中Go API压测等待20us,Java API压测等待2ms。
测试工具
主要测试工具:FinoTrade API(Go)压测代码编译为二进制程序,N和n值以参数的形式给出;FinoTrade API(Java)通过maven执行。
辅助测试工具:excel
测试结果及分析
注:为保证数据的准确性,每种场景均压测多次后取平均值,此节给出的数据为平均值,故存在小数。
此份报告中统计msg总数N=1000000
每轮pub的msg数n=1,2,4,5,10,20,40,100,,,N
FinoTrade API(Go)测试结果
按照4.1的三种大场景组合
-
FinoTrade API(Go) + FIX消息 + docker bridge
-
FinoTrade API(Go) + FIX消息 + docker host
3.FinoTrade API(Go) + FIX消息 + 物理机
-
FinoTrade API(Go) + ProtoBuf消息 + docker bridge
-
FinoTrade API(Go) + ProtoBuf消息 + docker host
-
FinoTrade API(Go) + ProtoBuf消息 + 物理机
-
FinoTrade API(Go) + Binary消息 + docker bridge
-
FinoTrade API(Go) + Binary消息 + docker host
-
FinoTrade API(Go) + Binary消息 + 物理机
FinoTrade API(Go)测试结果分析
吞吐量与时延的关系以折线图的方式记入,如下图:
测试参数:
消息编码:FIX vs. ProtoBuffer vs. Binary
发布环境:Docker-Bridge vs. Docker-Host vs. 物理机 (docker version 1.12.3)
Publisher, broker, subscriber 在同一机器上
使用Go API测试结论:
-
Proto buffer 和Binary, 每秒小于20,000条信息的延迟是200-300微秒
-
FIX 每秒小于20,000条信息的延迟是600微秒
-
逐渐增加n值,吞吐增加,平均时延亦增加。
-
当吞吐增加到某个值后,再增大吞吐,平均时延疾速增加。此时的“转折点”即为相对最优性能点。
-
在不同环境下性能对比:docker host模式略低于物理机模式,但远优于docker bridge模式。
FinoTrade API(Java)测试结果
按照4.1的三种大场景组合
-
FinoTrade API(Java) + FIX消息 + docker bridge
-
FinoTrade API(Java) + FIX消息 + docker host
-
FinoTrade API(Java) + FIX消息 + 物理机
-
FinoTrade API(Java) + Proto消息 + docker bridge
-
FinoTrade API(Java) + Proto消息 + docker host
-
FinoTrade API(Java) + Proto消息 + 物理机
-
FinoTrade API(Java) 极限压测数据(最大QPS)
不断增加发送端的压力,直到系统吞吐量不再上升,而响应时间拉长。这时已出现性能瓶颈,可以获得相应的系统最大吞吐量。
FinoTrade API(Java)测试结果
吞吐量与时延的关系以折线图的方式记入:
极限压测数据:
测试结论:
-
在不同一个测试环境下,FIX消息与ProtoBuf消息的吞吐对比,FIX消息的性能略逊于ProtoBuf消息。
-
同一种消息格式,在不同的测试环境下,性能Bridge < Host ≈ 物理机。
-
在消息不产生堆积的情况下(即每轮只pub一个消息),此时时延最低。其中ProtoBuf在物理机下的性能最优时延为207us左右,FIX在物理机下的性能最优时延为222us左右。
有任何疑问,请留言~
-