环境信息
- EMQX 版本：4.2.9
- 操作系统及版本：Red Hat 4.8.5-39
- 其他
问题描述
使用tcp(mqtt)方式，Qos=2，接收端数量=1，发送端能达到3500左右(payload=1k), 再往上就出现数据丢失(假如设置为发送端3600，每个端发送10次，则总共36000条消息，但接收端达不到36000条)
想知道哪些参数能提高发送端数量这一块的性能？ 另外如果是WSS协议，哪些参数可有同样的优化效果。
配置文件及日志
在默认配置参数下，已经对以下参数进行调整，–>前是默认值，–>后是调整后的数值
zone.external.max_inflight 32–>3200
zone.external.max_awaiting_rel 100–>10000
zone.external.max_mqueue_len 1000–>100000
zone.internal.max_inflight 128–>2800
zone.internal.max_awaiting_rel 1000–>100000
zone.internal.max_mqueue_len 10000–>1000000
不丢消息的话，QoS1 其实已经非常好了，QoS2 是牺牲速度和效率带来的质量。首先是不用依赖 QoS2 级别的消息去做高 IO 业务，设备消费不过来 crash 了丢的更多。要从业务设计上保证完整。HTTP协议就是QoS1的，我们也不会认为他就容易丢消息，而是主要靠处理业务的逻辑。
至于提高收发效率，EMQX 一直都是设备能接收发送多少，我们就按照最高处理。还有不推荐配置
zone.internal.max_mqueue_len 10000–>1000000
这么高的队列，设备消费不过来，如果挂了就丢完了。还有队列长并不能改善消费慢，队列再长终有尽时。
前面的参数我也不建议你修改，默认其实是最佳时间了，修改都是为了支持弱网或者处理速度慢的设备。
发送端可以做多线程的，一个线程发布速度你不满意，可以多个同时发。订阅使用共享订阅，多少设备同时消费即可。参考文档
谢谢大佬解答。
我这边发送端是100并发/秒；
一开始用默认参数，觉得发送端数量不够理想，所以才去修改配置项；
测试的数据如下：
测试场景相关项如下：
1 个赞
接收端要加线程，使用共享订阅来做，性能会更好。
按着你的业务，大概可以抽象成 N 多 producer，一些consumer，不要让个位数的线程来消费这么多消息。
谢谢。
再请问一下，如果我当前这种业务方式前提下。消息接收速率是否也是一个影响因素？
是的。其实我的意思就是要说消费端&生产端的速率匹配要合适
消费端的线程数宁多勿少，没有消息的时候，可以空载的，MQTT保持链接消耗不多的，本身也是为了长链接设计的协议。
谢谢。
我这边先调整一下消息订阅方式再看看。
再请教一下，前文说到的消息接收速率，是 listener.tcp.internal.active_n 还是 listener.tcp.internal.max_conn_rate
第一个，第二个是连接速率，即设备登录之前发起tcp连接时的限制
请问有微信交流群吗？
再请问一下，对于配置项的默认值，是否改为0(无限制)，能提升效果呢？
对于下图中这种接收数量是正确(与client端实际发送消息数一致)，但发送数量明显偏少(已知一个限制条件是emqx容器分配的cpu资源接近上限)，一般的瓶颈在哪里(配置参数可调整优化的项)？
qos=2，1600个发送线程(每1秒并发100，发送100次)，1个接收线程；
配置项：
zone.external.max_inflight 0
zone.external.max_awaiting_rel 0
zone.external.max_mqueue_len 0
zone.internal.max_inflight 0
zone.internal.max_awaiting_rel 0
zone.internal.max_mqueue_len 0
listener.tcp.external.active_n 10000
