4. FinTrade性能测试报告

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左右。

    有任何疑问，请留言~

    0