对emqttd做benchmark的时候遇到的几个坑

为了测试emqttd在我们的刀片机上面的性能，我们做了一次benchmark，遇到了几个有意思的问题

使用emqttc全力发送pub反而吞吐下降了

官方使用emqttc做了一个benchmark工具，其中有一个pub端，可以起n个连接，每隔m毫秒发送一个数据包。其实现隔时间发送publish的功能，是通过erlang的time模块每隔一定时间就往发送者线程发送一个publish消息实现的。发送者线程收到publish，就调用一次emqttc的publish，进行一次发消息操作。为了解除publish的最小1ms的限制，我去掉了time模块的调用（因为time的send interval调用最小的时间间隙就是1ms），改而使用调用了emqttc的publish之后，马上发一个publish消息给自己，这样本地马上又会再收到publish消息，马上发下一次的消息。

然而，之前1ms一个publish，接收方收到的数据的速度还能达到1000 msg/s，但是我放开1ms的限制之后，接收端收到的数据反而下降了，减少到了200 msg/s。仔细观察了tcp链路的包，并不忙碌。最后定位到问题，实际是因为erlang在调度的时候，发送者线程一直收到publish请求，一直在调用emqttc的publish，但是一直给自己发消息，导致了发送者线程一直占用cpu，而没有给发送者cpu，发送者实际发出的包反而少了

局域网内的机器ops起不来

我们在emqttd的运行机器上，跑benchmark，基本他的扇出可以达到10w msg/s，但是当我们在局域网的其他机器上跑客户端，就怎么都跑出这个效果。一开始考虑到可能是客户端的cpu压力过大（我们跑了10个发送者，50个接收者），于是我们分散了一下客户端。然而，发送者还是不能把所有请求下发给客户端。为了算清楚瓶颈具体在哪里，我们做了简单的计算。我们用的benchmark工具还是每个连接，每秒发送1k消息。10个发送者，一秒pub 1w条消息。50个sub，一秒扇出就高达50w。计算下来，似乎远高于本地benchmak结果，于是我们只好换其他方法测试了。

我们修改了测试模型。

我们先做了一个pub，一个sub的情况，hmm，因为benchmark工具的原因，似乎跑不出压力，只能跑到1k msg/s。于是我们换了benchmark工具，该工具纯粹发送消息，不做接收。但是似乎也不太对，只跑到了2k msg/s的发送。压力仍旧没有打满

我们又做了多个pub，一个sub，的测试。pub端每个连接都是1k msg/s，然而跑到17k/s，也到极限了，跟本地的10w/s相差还是比较大。看来也不行。

一个pub，每秒1000msg，然后我们在一个机器上起了30个client，嗯，很稳定。然后我们逐渐增加，就开始出现抖动了。不对，也还是3w msg/s的扇出而已。于是我们起了另一个机器，继续sub，发现新的机器的下发是稳定。于是我们在新的机器也起了20多个sub端，之后也开始出现了抖动。这个时候，服务器仍旧没有压力。所以看起来瓶颈不在服务器，而是客户端。仔细查看之后，我们发现，实际就是机器网卡的带宽被打满了，不能hold住继续增加的流量。

于是我们找到了一台能hold住更多流量的机器，然而，当客户端跑到40个的时候，也开始hold不住了。这个时候流量比之前多了一倍，但是那个机器的网卡带宽是之前的10倍，所以还是不对，仔细检查，是客户端的cpu被打满。好吧，我们只能增加机器。

最后的最后，通过一个pub，多个sub的方法，我们把机器的性能压榨到一个比较极限的情况，证明在我们的配置下，这个设备至少能扇出27w msg/s。虽然因为我们手头客户端数量的问题，这个压力还不是最大压力就是了。