我正在与tsung一起进行分布式负载测试，以测试我的mqtt消息代理。我的消息代理现在可以理想地处理1万个连接。当iam用tsung进行10k并行连接测试时，我意识到我在服务器中的tcp连接正在关闭。
我设置了端口范围并增加了ulimit，但仍然可以使用tsung生成用户，但无法在服务器上获得1万个并发连接。
我什至使用其他名为mqtt-bench的工具测试了代理，因为它可以生成并行连接，并且在这里tcp连接不会关闭。在tsung上是否缺少任何配置？
tsung版本为1.7.0，erlang版本为10.1
答案 0 :(得分：0)
这很可能是您达到服务器进程的默认ulimit。
通常进程一次限制为1024个打开文件句柄（一个打开的套接字由文件句柄支持）。
您可以使用ulimit命令查看当前的软/硬限制，然后将限制临时更改为硬限制。您可以通过编辑/etc/security/limits.conf文件来进行永久更改。
答案 1 :(得分：0)
在处理多个客户端时，我遇到了类似的问题。原因之一是您使用相同的客户端ID连接到mqtt服务器。
例如，如果客户端A以名称（client1）连接到MQTT服务器，然后客户端B以相同名称（client2）连接到MQTT服务器，则它将断开旧连接。这可能是最简单的原因之一
答案 2 :(得分：0)
如果没有证据，我们相信你的话，与MQTT台上的你得到更多的 超过1024个连接。 （A netstat的-a -n | grep按1883年|厕所-l就足够了 向我证明。）
如果是这样，这将表明，这个问题是不与任何代理配置， 但使用您的TSUNG配置。就是你不证明你的宗法进程 具有较高的限制，例如。 cat / proc / PROCNUMBER / limits，其中PROCNUMBER是进程 您的聪的数量。
一旦你已经证明了这一点，那么下一步将是启动的最大数量 与TSUNG配合使用的连接，然后启动Wireshk，然后再启动一个 与其他一些客户端连接。 PCAP将准确显示正在发生的事情。如果新连接失败，则 原因与连接成功的原因不同，还有其他一些原因 客户端获取断开。
我们一直在这样做，如本博客文章https://gambitcomm.blogspot.com/2016/06/how-is-realistic-mqtt-testing-different.html和我们博客中的其他文章所详述。
答案 3 :(得分：0)
您是否在客户端实例 fs.file-max = 100000 的以下位置将文件描述符限制增加为 /etc/sysctl.conf
随着您增加打开限制，上述文件描述符限制也需要更新。
请检查您的客户端实例是否有足够的内存（比如 8 核，16GB RAM）。此配置兼容您使用 tsung 脚本创建 10k 并发用户的负载，其中包含 3 个事务（连接、身份验证和发送消息）。
注意：在运行测试时监控 CPU 利用率！