Комментарии 17
Очень интересно, обязательно пишите еще!
Из вопросов (или я где-то чего-то не понял):
- Можно ли как-то распределять нагрузку (например, гарантированно выполнить какой-то кейс N раз за M минут)? Как это настраивается (желательно, реальный пример)?
- Можно ли добавлять свои метрики в результаты теста? Было бы полезно иметь некий event, привязываясь к которому выполнять процедуры сбора данных (как пример, сбор метрик утилизации, метрики из БД, бизнесовые данные из БД и т.д.)
- Есть ли инструменты или может какие-то наработки в области конвертации записанного трафика (например, в формате HAR) в готовый сценарий тестирования?
- Есть ли режим эмуляции браузера в плане загрузки ресурсов, т.е. когда в несколько потоков загружаются ресурсы страницы?
НЛО прилетело и опубликовало эту надпись здесь
- не уверен, т.к. рандомность задач — одна из фишек, продвигаемых разработчиками. Есть только идеи — попробую проверить, одна из них — распределенный тест с конкретными задачами для каждого исполнителя
- есть ивенты, на которые можно подписаться
- был опыт, но тогда задача свелась к написанию своего тула с нуля
- можно добавить в хедеры информацию о браузере
Мне же JMeter никогда не нравился из-за неочевидного интерфейса и высокого порога вхождения, как только возникает необходимость протестировать не Hello World приложение.
У меня двоякое чувство от этого предложения.
С одной стороны Вы пишете, что интерфейс неочевиден, хотя куда что очевиднее GUI может быть, с другой стороны Locast ничего другого, кроме Hello World, по видимому и не может, но он Вас устроил, почему?
— только поддержка только http
— нет средств серверного мониторинга. Время отклика страницы без CPU/RAM это мягко говоря цифра совершенно бесполезная.
— нет расширенных инструментов, для управления данными (да, jm тоже не богат, но сделать быстрый data in/out там можно несколькими способами)
— нет db коннектора, базу например не отпрофилируешь, не посмотришь опять таки метрики (память/calls/QPS и другое)
— отсутствие системы плагинов, возможно ошибаюсь, но то что есть в локасте — это мало, и оно для приложений как раз больше HW, мало чем подходит. (да, std поставка jm тоже не самая кошерная, но ее можно легко изменить под нужны)
— jm имеет кучу встроенных листенеров/обработчиков, которые просто работают. Распарсить html, запустить js и прочее. Это все есть, было и будет, в отличии от python библиотек, с которыми в первую очередь нужно разобраться, а во вторую — они имеют привычку протухать особенно для всяких не-RFC стандартов, по типу socketIO от js комьюнити (как же я его ненавижу)
Итог получается какой то интересный: jm мне не нравится и плохой, потому что я его «ниосилил», и потому что он может больше, чем мне нужно.
Мне кажется locust и jm — это как notepad и visual studio, да и там и там можно писать текст в редакторе, но сравнивать их совершенно не корректно.
Я хоть и не знаком пока непосредственно с locust, но с вами не соглашусь немного. Т.к. скрипты пишутся на Python, то это значит что:
- Нет отграничений только в рамках http (это скорее нативный код заточен под http, но фактически можно написать все что угодно).
- Про мониторинг я сам спрашивал выше, но предполагаю, что можно создать просто отдельного пользователя, который будет эти метрики собирать (в том числе и из БД). В крайнем случае для сбора метрик можно использовать сторонние инструменты. Да, это неудобно, но это не ограничение.
- Профилирование БД так же вероятно возможно (см. п.2).
Ну вот видите, все вытекает из слов:
когда в jm это есть — просто используй.
Хотя, положа руку на сердце, в jm тоже есть бесячие моменты (кучерявые графики например), я не отрицаю, но приведенная неочевидность — явно не про него.
но фактически можно написать все что угодно
когда в jm это есть — просто используй.
Хотя, положа руку на сердце, в jm тоже есть бесячие моменты (кучерявые графики например), я не отрицаю, но приведенная неочевидность — явно не про него.
Ну это как минимум то, чего мне не хватает в JM — возможность скриптовать сценарии.
А тут как бы и любимый Python, и относительная свобода.
А по поводу недостатков, так никто не ограничивает нас только этим инструментом, те же метрики можно собирать JMeter-ом, параллельно с тестом, и вызывать его с коммандной строки при старте теста, останавливать при остановке теста.
Не холивара ради, но как минимум выглядит такое сочетание любопытно. И locust вполне может играть роль связующего звена для всего этого комбайна.
Простите, но чем Вам artillery не угодил?
НЛО прилетело и опубликовало эту надпись здесь
В свое время аналогичную проблему (стресс-тест веб-приложения), я решил созданием небольшого распределенного приложения (на java, тогда еще 1.4, потом 5-я теперь 7я). На вход которого подавался файл с ссылками, полученный от Яндекс.вебмастера. Раньше у Я.Вебмастера не было ограничения на кол-во выгружаемых в файл записей, поэтому легко получались реальные тест-кейсы по 2..3..4 млн ссылок (включая «ошибочные» и т.п.).
На нескольких VPS в разных дата-центрах, запускаются пулы этаких «реквестеров», каждому из которых централизованно передается какая то часть ссылок из файла с данными. Также, передаются настройки, сколько потоков запускать, с каким периодом ожидания, нужно ли «парсить» получаемый html (например для проверки наличия тега H1 или соответствия его содержимого некоему шаблону).
Реквестеры, в процессе работы, отсылают на управляющий сервер свою текущую статистику (сколько запросов выполнил каждый их поток, какое среднее время ответа, % ошибок и тому подобное)
Далее подключаем к тестовому аппликейшен серверу jprofiler и наслаждаемся :) ну или в срочном порядке решаем проблему если сразу «все плохо». Нагрузка которую выдерживает тестовый стенд (ну например с метрикой полное «время генерации не больше 1000мс»), практически на 98% совпадает потом с реальной нагрузкой которую приносят на продакшен сервер живые посетители и поисковые боты.
Сейчас Я.Вебмастер дает только 500тыщ ссылок, поэтому дополняем входные данные из файлов access логов.
На нескольких VPS в разных дата-центрах, запускаются пулы этаких «реквестеров», каждому из которых централизованно передается какая то часть ссылок из файла с данными. Также, передаются настройки, сколько потоков запускать, с каким периодом ожидания, нужно ли «парсить» получаемый html (например для проверки наличия тега H1 или соответствия его содержимого некоему шаблону).
Реквестеры, в процессе работы, отсылают на управляющий сервер свою текущую статистику (сколько запросов выполнил каждый их поток, какое среднее время ответа, % ошибок и тому подобное)
Далее подключаем к тестовому аппликейшен серверу jprofiler и наслаждаемся :) ну или в срочном порядке решаем проблему если сразу «все плохо». Нагрузка которую выдерживает тестовый стенд (ну например с метрикой полное «время генерации не больше 1000мс»), практически на 98% совпадает потом с реальной нагрузкой которую приносят на продакшен сервер живые посетители и поисковые боты.
Сейчас Я.Вебмастер дает только 500тыщ ссылок, поэтому дополняем входные данные из файлов access логов.
Странно видеть в одном предложении Python и «нагрузочное тестирование» и не видеть Я.Танк.
Яндекс.Танк и BFG не пробовали?
Искренне считаю, что людям комфортно себя чувтсвующим с любым языком программирования эта штука и не нужна совсем. Усилий на освоение нужно моного, а оттдача сомнительна. JMeter безумно коряв и нестабилен, но два запроса на нем руками сделать быстрее, чем в любом коде. Запись опять же. Я в недоумении.
Добрый день! Вы сталкивался с проблемой debugging'а Python+Locusrt скрпипта? Как вы производили отладку кода?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Нагрузочное тестирование с locust