FinTrade性能测试报告


  • administrators

    测试目的

    本报告为FinoTrade产品交易总线的压力测试报告,其目的在于统计在不同的测试场景下总线的压测情况,指标包含吞吐量和时延,并根据压测结果判断当前总线性能是否已达到最优。

    测试环境

    0_1535339110181_01.jpg

    测试案例

    测试覆盖

    • 消息协议:FIX、Protobuf、Binary(java暂不支持)

    • API:FinoTrade API(Go)、FinoTrade API(Java)

    • 测试环境:docker host模式、docker bridge模式、物理机

    测试方案

    • 测试案例简述:启动两个不同的进程,一个进行用于pub、一个进程用于sub

    • 测试前提:pub、broker、sub在同一台机器

    消息大小:
    0_1535350811394_01.jpg

    测试步骤:

    • 给定需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的三种大场景组合

    1. FinoTrade API(Go) + FIX消息 + docker bridge
      0_1535352709706_02.jpg

    2. FinoTrade API(Go) + FIX消息 + docker host
      0_1535352777183_03.jpg

    3.FinoTrade API(Go) + FIX消息 + 物理机
    0_1535353085107_03.jpg

    1. FinoTrade API(Go) + ProtoBuf消息 + docker bridge
      0_1535353652040_04.jpg

    2. FinoTrade API(Go) + ProtoBuf消息 + docker host
      0_1535353884094_05.jpg

    3. FinoTrade API(Go) + ProtoBuf消息 + 物理机
      0_1535354281240_06.jpg

    4. FinoTrade API(Go) + Binary消息 + docker bridge
      0_1535354639428_07.jpg

    5. FinoTrade API(Go) + Binary消息 + docker host
      0_1535355430510_08.jpg

    6. FinoTrade API(Go) + Binary消息 + 物理机
      0_1535355487592_09.jpg

    FinoTrade API(Go)测试结果分析

    吞吐量与时延的关系以折线图的方式记入,如下图:
    0_1535355558265_01.jpg

    测试参数:
    消息编码: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的三种大场景组合

    1. FinoTrade API(Java) + FIX消息 + docker bridge
      0_1535356981581_01.jpg

    2. FinoTrade API(Java) + FIX消息 + docker host
      0_1535357037601_02.jpg

    3. FinoTrade API(Java) + FIX消息 + 物理机
      0_1535357092008_03.jpg

    4. FinoTrade API(Java) + Proto消息 + docker bridge
      0_1535357309222_04.jpg

    5. FinoTrade API(Java) + Proto消息 + docker host
      0_1535357445638_05.jpg

    6. FinoTrade API(Java) + Proto消息 + 物理机
      0_1535357978787_06.jpg

    7. FinoTrade API(Java) 极限压测数据(最大QPS)
      不断增加发送端的压力,直到系统吞吐量不再上升,而响应时间拉长。这时已出现性能瓶颈,可以获得相应的系统最大吞吐量。
      0_1535359118651_07.jpg

    FinoTrade API(Java)测试结果

    吞吐量与时延的关系以折线图的方式记入:
    0_1535359195548_08.jpg

    极限压测数据:
    0_1535359277430_11.jpg

    测试结论:

    • 在不同一个测试环境下,FIX消息与ProtoBuf消息的吞吐对比,FIX消息的性能略逊于ProtoBuf消息。

    • 同一种消息格式,在不同的测试环境下,性能Bridge < Host ≈ 物理机。

    • 在消息不产生堆积的情况下(即每轮只pub一个消息),此时时延最低。其中ProtoBuf在物理机下的性能最优时延为207us左右,FIX在物理机下的性能最优时延为222us左右。

    有任何疑问,请留言~