2018-12-06

接口性能测试文档(预生产)：

目标

后端接口性能测试前需要有量化目标。例如：

• N用户登录（或不登录状态），观察K线，买卖单及实时成交，时间延迟及错误率
• N用户并发下, 90%， 95%， 99%样本挂买卖单失败率，时间延迟及错误率
• N用户查看当前委托、历史委托，90%， 95%， 99%样本失败率，时间延迟
• N用户查看历史成交90%， 95%， 99%样本失败率，时间延迟

硬件配置

服务器名称	数量	CPU	内存	带宽(Mb)
MDP	1	4	16	20
Order	1	1	8	20
FullNode(*)	1
Trade	1
Gateway
Faucet

可能存在瓶颈的接口

• get_market_history
• limit_order_create
• fillorder_history
• getDepth
• getOpenOrder
• getClosedOrder
• gatewayRecord

数据准备

• 200个账号
• 因为挂、撤单需要手续费，所以账号中需要有一定的CYB和其他测试币
• 对部分(50%?)账号需要造一些历史成交记录

测试环境压测

对于中心化服务，例如MDP, Order, RTE, OP server. 可以在测试环境先做压测.

Order server压测

测试节点

wss://shanghai.51nebula.com

硬件

服务器名称	数量	CPU	内存	带宽(Mb)
Order	1	1	8	20

压测结果

建立800个ws, 20Mb带宽下错误率报告

建立800个ws, 20Mb带宽下聚合报告

在带宽为1Mb, 10Mb, 20Mb下测试了节点的响应时间，错误率等。当建立800个websocket连接时，client端开始出现报错信息。节点主要瓶颈在带宽，20Mb带宽下吞吐量为200+，此时CPU占用率50%。生产环境可以适当考虑增加服务器带宽。

MDP server压测

测试节点

wss://mdp.cybex.io

硬件

服务器名称	数量	CPU	内存	带宽(Mb)
MDP	1	4	16	20固定

压测结果

建立400个ws,20Mb带宽下错误率

在20Mb带宽下，建立200个websocket连接，client端运行正常。但是当继续扩大ws连接数时，错误率急剧上升，penny在正在debug原因。

Trade server压测

测试节点

http://47.107.136.146:8081

硬件 -> 主要压力在MongoDB

服务器名称	数量	CPU	内存	带宽(Mb)
Trade

压测结果

1000无cache并发错误率

1000无cache并发吞吐量

1000并发下开始出现错误。99%样本接口返回时间为8.3秒，平均返回时间在4秒+。这个时间有点长。需要Laurie看一下。

全节点压测

测试节点

wss://shanghai.51nebula.com

硬件（做了负载均衡，ws连接超过600时触发）

服务器名称	数量	CPU	内存	带宽（Mb）
FullNode	1（动态）	2	8	20（动态）

压测结果

建立500个ws并发错误率

建立500个ws并发聚合报告

在建立500个ws连接时，history和db API接口开始出现错误。和yoyo一起看了下结果，发现有的接口太重，可以用更轻量级接口替代。例如前端需要account balance可以通过get_account_balances接口而不是get_full_accounts去拿结果。

结论

• 系统主要瓶颈在MDP，当ws订阅连接超过200时，订阅接口返回错误，拿不到最新数据
• Trade DB(历史成交)未来随着成交数据量增大必然会出现瓶颈。因为mongo需要从大量数据中（当前是300G左右）查找用户的历史成交，而且需要实时响应，接口返回时间会增长（当前是8s），影响用户体验。建议做冷热数据分离，只返回类似于近三个月的数据
• order db, get_opened_limit_order_status接口会返回用户所有挂单数据，且无法分页，所以当用户当前委托单太多时，会有潜在的性能问题
• 附各服务（单节点）下并发无错误上限

服务器名称	数量
MDP	200
Order	1400
FullNode	400
Trade	1000

Thanks everyone involved.