Комментарии 16
Незаслуженно забыты 2 отличных инструмента:
1. https://github.com/artilleryio/artillery — js, конфиг через yaml. Очень шустрый. Куча возможностей из коробки.
2. https://github.com/aliostad/SuperBenchmarker — констольный под win, mac. Простой и быстрый, строит красивые графики. Конфиг ключами.
Интересное сравнение, спасибо.
Времена отклика на графиках в миллисекундах?
В скрипте Gatling вижу проблему - неправильно использован pacing. Установлено значение 2мс, однако запросы выполняются дольше, что приводит к снижению интенсивности и поэтому cpu не утилизируется выше 65%. Можно попробовать провести повторный тест с pacing 40мс и до 1500 конкурентных сценариев или выше (желательно установить pacing выше максимального времени выполнения сценария и расчитать число конкурентных сценариев соответственно).
Если нет необходимости в закрытой модели нагрузки, то можно использовать открытую модель, тогда не придётся расчитывать и использовать pacing.
Если интересует именно RPS, можно также включить общий пул подключений, что позволит ещё немного увеличить интенсивность.
Было бы интересно увидеть насколько изменятся результаты)
По бест-практис всё-таки стоит разделять генератор и тестируемое приложение. CPU steal time 95+ процентов в явном виде указывает, что виртуалка находится в ожидании выполнения на хосте. Хоть тулы были примерно в равных условиях, проводить сравнение в такой конфигурации, имхо, некорректно.
Так они же и разделены, генератор нагрузки на виртуалке, тестируемое приложение на хост машине, конечно они могут влиять друг на друга, но и в реальной жизни такое возможно, когда виртуальная машина генератора нагрузки и приложения нарезаны с одной хост-машины. По поводу CPU steal time 95+, моя вина, подложил не очень очевидный график, он показывает значение в стеке и накладывает друг на друга нулевые графики. В реальности steal time максимум 0,782%
Сравнение явно полезное, но из коробки k6 поддерживает намного больше протоколов: https://k6.io/docs/using-k6/protocols/ и для k6 лучше было использовать сценарии (https://k6.io/docs/using-k6/scenarios/executors/), а не старую модель со stages/target - предполагаю, что у вас получились бы совсем другие числа.
Для locust не совсем верное тестирование, в виду его однопоточной python жизни, необходимо запускать slave ноды: http://docs.locust.io/en/stable/running-distributed.html по количеству CPU, как раз для их утилизации
Для тестирования использовалась версия k6 v0.36.0. Использовался примерно такой же подход к формированию скрипта пауза между итерациями 10 мс. Запуск 200 виртуальных пользователей за 10 минут.
А в чём смысл такого теста производительности инструмента, если она искусственно ограничивается через задержки?
Не могу однозначно сказать за другие инструменты, т.к. плотно использовал только Tsung, который не представлен в этом сравнении. Но последнее время активно смотрю в сторону K6, периодически тестирую его и считаю очень перспективным. Поэтому такой низкий результат меня сильно удивил.
Попробовал частично воспроизвести тест на двух облачных виртуалках. Если просто закомментировать sleep в вашем сценарии k6, получается прирост с 8.6k rps до 41K rps.
Задержки устанавливаются не для искуственного ограничения, а для управляемого и предсказуемого роста нагрузки, все таки это важно при тестировании производительности. Честно сказать, результат K6 меня тоже удивил, возможно у меня были какие то ошибки при его использовании, но пока не понятно какие. В моем случае без задержки K6 быстро съедает все ресурсы виртуалки и начинает вести себя нестабильно, при этом результат не сильно меняется.
Это интересно. Не очень понятно, как такой тип теста (closed-model, с лимитированным количеством юзеров) может начинать вести себя нестабильно, разве что значение "max users" выбрано слишком большим для тестового окружения.
В любом случае, использовать искусственную задержку неправильно для такого вида теста, иначе не понятно, производительность чего в итоге тестируется? Учитывая, что в концу теста у нас 200 virtual users в цикле посылают запросы и ждут 0.01 секунду, то общее число итераций в секунду даже без отправки запросов может быть максимум
1/0.01*200 = 20000
Если спать 0.02 секунды, получим 10000. Вопрос - а при чём здесь k6 тогда? :)
P.S. Полная копия вашего 10-ти минутного теста с закоментированным sleep выдает 45K reqs/s без единой ошибки.
1/0.01*200 = 20000
В том то и дело, что даже 20к не получилось. Да конкретный сценарий больше 20к не может выдать, но даже если указать ему не 200, а 2000 или 20000 вюзеров, результат не изменится.
P.S. Полная копия вашего 10-ти минутного теста с закоментированным
sleepвыдает 45K reqs/s без единой ошибки.
Тут уже вопрос в каком окружении и сколько ресурсов ему для этого понадобилось, у меня все инструменты запускались в одинаковой, ограниченной среде.
Спасибо за K6, надо посмотреть на него внимательнее.
В своей не очень широкой практике использовал еще вот такое:
1) wrk https://github.com/wg/wrk для совсем простой нагрузки, зато выдает 100K+ RPS
2) pandora https://github.com/yandex/pandora - пушка от яндекс-танка на Go, есть сценарии
3) molotov https://molotov.readthedocs.io/en/stable/ - минифреймворк на Python/asyncio для сценариев со сложной логикой
И да, как уже упоминалось, при замерах RPS имеет смысл физически разделять хосты - источники и приемники нагрузки, чтобы не возникало никакой конкуренции за ресурсы (источник на хост-системе, приемник в виртуалке - это немного не то)
Попробуйте для Locust использовать FastHttpUser вместо обычного HttpUser. Также, если запустить в распределенном режиме (для 4-ядерного процессора - это 1 мастер и 3 воркера), результаты будут не такими скромными :)
Апаче хорош!
Сравнение производительности инструментов нагрузочного тестирования