Во время тестирования нагрузки tsung соединения tcp закрываются после 1024 соединений

Question

Я работаю над распределенным нагрузочным тестированием с помощью tsung, чтобы проверить мой брокер сообщений mqtt. Мой брокер сообщений теперь может идеально обрабатывать 10 тыс. Соединений. Когда я тестировал его с помощью tsung для 10k параллельных соединений, я понял, что мои соединения tcp на сервере закрываются.

Я установил диапазон портов и увеличил ulimit, но все же я мог генерировать пользователей с помощью tsung, но не мог получить 10k одновременных соединений на сервере.

Я даже протестировал брокера с другим инструментом под названием mqtt-bench в этом я мог бы генерировать параллельные соединения, и здесь соединения TCP не закрываются. Есть ли какая-либо конфигурация, которая отсутствует на Цунг?

и версия tsung 1.7.0, версия erlang 10.1

Answer 1

У меня были похожие проблемы при работе с несколькими клиентами. Одна из причин заключается в том, что вы используете тот же идентификатор клиента для подключения к серверу mqtt.

Например, если клиент A подключен к серверу MQTT с именем (client1), а затем клиент B подключен к серверу MQTT с тем же именем (client2), он отключит старое соединение. Это может быть одной из самых простых причин

Answer 2

Скорее всего, вы используете ограничения по умолчанию для процесса сервера.

Обычно процессы ограничены 1024 открытыми файловыми дескрипторами одновременно (открытый сокет поддерживается файловым дескриптором).

Вы можете использовать команду ulimit, чтобы увидеть текущие мягкие / жесткие ограничения и временно изменить ограничение до жесткого ограничения. Вы можете вносить постоянные изменения, редактируя /etc/security/limits.conf файл.

Answer 3

Без доказательства, мы поверим вашему слову, что с mqtt-bench вы получите более 1024 подключений. (Netstat -a -n | grep 1883 | wc -l было бы достаточно, чтобы доказать это мне.)

Если это так, это означает, что проблема не в какой-либо конфигурации брокера, а в вашей конфигурации TSUNG. То есть. Вы не доказываете, что ваш процесс цунга имеет более высокие пределы, например. cat /proc/PROCNUMBER/ ограничивает где PROCNUMBER - номер процесса вашего цуна.

Как только вы докажете это, следующим шагом будет запуск максимального количества соединений, которые работают с TSUNG, затем запуск Wireshark и еще одно соединение с другим клиентом. PCAP покажет, что именно происходит. В случае сбоя нового соединения причины могут быть другими, чем если соединение установится успешно, и какой-то другой клиент будет отключен.

Мы делаем это постоянно, как подробно описано в этом блоге https://gambitcomm.blogspot.com/2016/06/how-is-realistic-mqtt-testing-different.html и других в нашем блоге.

Answer 4

Вы увеличили лимит файлового дескриптора как fs.file-max = 100000 в следующем месте клиентского экземпляра /etc/sysctl.conf

По мере того, как вы увеличиваете открытые лимиты, также необходимо обновить вышеуказанный лимит файловых дескрипторов.

Пожалуйста, проверьте, достаточно ли памяти в экземпляре клиента (скажем, 8 ядер, 16 ГБ ОЗУ). Эта конфигурация совместима для создания нагрузки из 10 тыс. Одновременных пользователей с 3 транзакциями (подключение, проверка подлинности и отправка сообщения) из сценария tsung.

Примечание. Следите за загрузкой ЦП во время выполнения теста!