Тестирование производительности: JMeter против Tsung

Tsung написан на Erlang и, как говорят, способен одновременно запускать огромное количество пользователей (10000+).

Jmeter написан на Java и вполне способен генерировать большие объемы нагрузки, если ваш план тестирования хорош.

Вот некоторые ограничения в отношении производительности в JMeter.

• Каждый пользователь в Jmeter — это поток ОС. Это увеличивает накладные расходы при одновременном использовании большого количества пользователей (рекомендации jmeter рекомендуют использовать небольшое количество потоков, http://jmeter.apache.org/usermanual/best-practices.html - по моему опыту, вы можете столкнуться с проблемами при использовании более 1000 потоков на экземпляр jmeter, но это может сильно различаться в зависимости от ваш план тестирования). Вам также потребуется настроить параметры JVM при выполнении более крупных тестов.

• Вы можете легко снизить производительность и исчерпать память PermGen, если у вас есть динамические сценарии (скрипты, которые необходимо каждый раз перекомпилировать из-за расширения переменной jmeter). Поместите свои скрипты в отдельные файлы или используйте ключ кэша компиляции, чтобы избежать перекомпиляции.

• Использование некоторых тестовых компонентов (таких как древовидное представление, которое хранит каждый запрос и ответ в памяти) может нанести ущерб вашему генератору нагрузки.

Я протестировал некоторые ОЧЕНЬ большие сайты с JMeter, и пока вы можете уменьшить количество потоков (уменьшив время ожидания пользователя, чтобы поддерживать пропускную способность на желаемом уровне), Jmeter в порядке. Существует довольно большое сообщество вокруг JMeter, плагинов для нагрузочного тестирования с использованием множества протоколов и мониторинга различных систем. JMeter также имеет хорошую поддержку сценариев - java, javascript, все, что может быть загружено в jvm в основном (включая, например, groovy), поэтому он очень расширяемый.

В свое время (думаю, используя jmeter 2.6) я выполнял около 30 000 запросов к базе данных в секунду (Oracle JDBC) от одного генератора нагрузки, и с тех пор были некоторые оптимизации, поэтому, пока у вас нет экстремальных требований, Jmeter в порядке. Выберите тот, который соответствует вашим потребностям и вашему опыту.

Примечание. У меня очень мало опыта использования Tsung.

Изменить: сейчас я использую Locust (https://github.com/locustio/locust/). Tsung не обновлялся с 2017 года, а модель пользователей/потоков Locust (greenlets) поддерживает больше одновременных пользователей, чем Jmeter. Но самое главное, у него более гибкий рабочий процесс (фактический код Python вместо настройки/щелчка в графическом интерфейсе).

Это всегда зависит от вашего сценария и количества данных, используемых для вариативности, соотношение близко к десяти, когда вы сможете запускать 100 пользователей в секунду с JMeter, Tsung будет легко с 1000 пользователей в секунду.