Я хочу не спросить совета, а поделится личным опытом.
Год назад мне надо было срочно провести нагрузочное тестирование, причем времени на изучение какого-то инструмента и подготовку сценариев тестов было в обрез.
После попыток понять JMetr я в конечном итоге нашла Gatling Tool.
Среди плюсов:
наличие рекодера. Для начинающих самое то. Тем более что тест можно записать, а потом при наличии уже какого-то опыта подкорректировать.
Поддержка девелоперов. В гугл-группе Gatling они в течении нескольких часов отвечают практически на все вопросы пользователей любого уровня.
Отчеты о прохождении тестов. Подробные, графические и доступны для понимания не специалистов
С одного компьютера можно открыть все необходимое количество сессий.
На каждого пользователя открывается своя собственная сессия. Так же вход пользователей на сайт можно варьировать (одновременно, с заданным промежутком, в течении какого-то времени, чтобы на тестируемом сайте постоянно находилось заданное число пользователей и т.д.)
Более формальную информацию о принципах работы можно почитать на их официальной странице и в wiki.
Из минусов для меня:
инструмент и сценарии пишутся на Scala
За тот год, что я тестирую с помощью Gatling они дважды кардинально меняли API. Т.е. годом ранее написанные тесты не идут на новых версиях, либо требуют доработки. Приходится сейчас держать две версии программы. В оправдание девелоперов скажу, что лично мне они помогли мигрировать часть тестов на новую версию.
Год назад я
а) была крайне слаба в автоматизации. Я и сейчас далеко не профи, но на тот момент нагрузочное тестирование для меня было что-то абсолютно инопланетное. Я, естественно, первым делом сунулась изучать JMetr и поняла, что ничего не понимаю. Поэтому наличие рекодера при очень кратких сроках на выполнение задачи было огромным плюсом.
б) Мне надо было эмулировать одновременный вход 150 пользователей. Почитав тот же хабр и другие заметки по JMetr я вынесла оттуда информацию, что сделать с одной машины я это не смогу. Нужны будут как минимум дополнительные виртуалки, откуда я смогу запускать тесты и т.п. Если смотреть пункт первый я бы это просто не осилила. А в Гатлинге можно просто задать количество пользователей и не надо никаких дополнительных машин.
в) У нас не было нужды в досконально точных измерениях (я уже поняла, что для более тонких задач действительно придется осваивать JMetr ). Важно было определится, выдерживает ли сервер 150 пользователей единовременно или нет. Если нет, то сколько максимально пользователей могут работать с системой и не просто работать, а выполнять определенные “толстые” действия и как долго будет отвечать система в этом случае. Гатлинг все это позволяет получить (при включения более подробного логирования).
Jmeter -> создать прокси сервер, запустить браузер, выставить нужный порт, и начать серфить по сайту… запоминает всё, потом останавливаешь сервер и смотришь полученные данные
но в общем, спасибо за интересную тулзу, нужно будет поподробней почитать
А что там с синхронностью, аналогично Jmeter? Просто из-за отсутствия пересечения асинхронности с поддержкой нужных фич в большинстве тулзов пришлось писать свой велосипед.
Хороший инструмент!
За счет внутренностей удобно кастомизируется для нагрузки actor-based систем.
Наверно следует уточнить какой сценарий имеется ввиду. Каждый пользователь гатлинга “независем” и держит свой Context. Каждый шаг, по сути это akka actor. Actor-ы очень слабо с друг другом связаны и асинк сценарии реализуемы.
@b1kers, очень интересен кейс велосипеда. пошарьте идею, какая задача стояла. Пожалуйста!
О да, это сама природа скалы. Отсуствие совместимости байт кода в мажорных версиях, и значительные изменения системы акторов (в первую очередь встраивание их в базовую scala)
Из своего опыта, я побоялся писать расширения для jmeter для не http. А так как разрабатываемая система scala+akka+rabbitMq, то проще оказалось расширить гатлинг, и поднатореть в имутабельных акторах.
Для меня то что я пишу код быстрее чем клацаю юай, огромнейший плюс по сравнению с jmeter, да и дебажить проще. Не нужен еще один велосипед - знаешь скала, можешь писать гатлинг тесты.
Ну и так от себя отмечу gatling-dsl - баловство , которое значительно понижает входной барьер в gatling. Огромный респект разработчикам.
Кейс велосипеда: нагрузить сервис, принимающий в теле POST-запроса json. Jmeter синхронен, если я не ошибаюсь, да и у него таки есть предел RPS. А в реальной жизни пользователи не выстраиваются в очередь, посему, требуется асинхронность. Не спорю, гатлинг, возможно бы справился и лучше, но я на тот момент не знал про него, пришлось написать скрипт на Twisted’е. Отмечу, что так же не любитель тыкать в кнопочки, а раз можно писать человеческие скрипты, то действительно можно особо не изобретая велосипеды, выполнить подобную задачу. В общем, спасибо за ответ.
Note: Далее просто мое понимание различий распараллеливание и асинка.
@b1kers, почему-то я вижу только возможность распараллеливания. Асинхронность - не блокирующие выполнение.
Пользователи - как раз параллельное выполнение.
Асинк - начать выполнение одного действия, не дожидаясь конца начать выполнение другого.
Асинк использует броузер пример async-http: начать загружать страницу, в середине начать подгрузку ресурсов – map, в конце/по ходу их совместить – reduce
Мне остается непонятно, какое это отношение имеет к серверу, в контексте нагрузки. Все запросы http, для сервера/серверов “эквивалентны”.
Т.к. сервера что спросили, то он и отдал. Выдуманный сценарий, который покрывается даже jmeter.
Пользователь: Посылает Create
Server: Сразу отвечает, и дает Id.
Server: Отдает запрос на запись хранилищу (Ответ id, клиенту не означает что запись была сохранена)
Пользователь: Посылает Get(Id)
Server: отвечает Id Not Found ИЛИ отвечает Записью
(это реальная ситуация с различными настройками арбитража хранилища на запись и чтение)
Мое мнение - тут асинк для клиента нагрузки - не нужен.
С чем jmeter, думаю не справится, это Послать Create и на ответ послать n*Get параллельно, и убедится, что в хотябы одном случае за разумное время данные были получены. И смотреть как меняется “разумное время” с ростом нагрузки. Но это опять же распараллеливание (имхо).
У гатлинга на даную часть есть возможность split, что облегчает моделирование подобного.
Внутрях, гатлинг использует async-http-client (ahc), но я бы не сказал, что это торчит наружу.
Я бы очень хотел понять когда нужен асинк. Это прямо расширит карту моего мира!
Прошу прощения за задержку. Постараюсь донести свою идею. Любой сервер, принимающий POST-запрос, должен как-то его записать/обработать. Мне нужна была модель в которой сразу после отправки одного POST-запроса, отправляется следующий и так для каждого из n отправляющих “клиентов”. А в Jmeter задается общая интенсивность. Суть в том, что при заранее заданном числе соединений(требование из ТЗ, например) такая нагрузка наиболее “тяжела” для сервиса. Возможно, я неправ, либо мое понимание асинхронности отличается от вашего или общепринятого. Как-то так.
Мне, вот, не понравилась документация: об api на setup сказано лишь в примечании к 2.0, раздел подключения к IDE совсем не верный (maven уже не используется, теперь там sbt)
При написании теста пару раз передёрнуло от логики api, но тем не менее всё оказалось просто и быстро.
Вцелом мне понравилось. Думаю, применять инструмент в дальнейшем.
Каждый пользователь гатлинга “независем” и держит свой Context.
Правильно ли я понял, что контекст всё-таки можно шарить. Ведь там можно обработчиком получить параметр из одного response и передать в другой request?
Action говорит (tell или в коде !) следующему актору Сессию
Сессия “имутабельна”, если один Action хочет передать следующему Action, несколько другую сессию, или сказать что пора остановится, или “проскипаться”, то создается новый объект сессии на основании предыдущего. Сессия, хранит последовательность шагов (имея ввиду Action) которые нужно выполнять.
Именно последний механизм и позволяет реализовать работу с респонсом (в данном случае один Action, вставляет полученный им респонс в новую сессию и говорит об этом следующему действию) и валидацию (полученный из сессии респонс или ответ сверяется, и опционально говорится следующему акшину, если упало, не идти дальше).
Имея опыт расширения gatling под свои нужды отмечу, до настоящего Context, который получен от akka, можно достучаться, но неуверен что это нужно. Это тернистый и опасный путь для распараллеливания, т.к. контекст “мутабельный”, хотя и “безопасный”, сессии должно хватить с головой.
P.S. Если перемудрил, дайте знать постараюсь описать по другому. Также может быть интересна модель параллелизации Actor Based.
Вы могли бы рассказать про свой опыт подробнее? Меня интересует именно способы расширения gatling, приминения его в нестандартных (отличных от тестирования сайтов) ситуациях. Я хотел бы дополнить свою картину в каких случаях какой инструмент я могу применить более эффективно.
По поводу расширения gatling я пока нашел одну статью Neo4j and Gatling sitting in a tree, Performance T-E-S-T-ing
То от чего мы отталкивались это вот это https://github.com/excilys/gatling/wiki/Protocol-support и ведет на линк толковый. Единсвенное модель Gatling 2.0 немного проще даже, мы использовали именно ее, и примеры становятся проще.
У нас часть продукта - “агент” actor based, и http протокола к нему нету. Поэтому написали свои экшены, с примитивным dsl, на основе модели, чтобы пулить “агента”.
Не очень любим “длинные” тесты, поэтому на данный момент экшины работают в форке sbt (“аналог” maven) процесса, и нет возможности запустить данные тесты против живой системы, но как понадобится - добавим. Решается это параметризацией Gatling Protocol.
Самое хитрое понять было что мерять, т.к. репорты gatling очень заточены под async-http и используют метрики (начало реквеста, конец реквеста, начало респонса, конец респонса), в асинк системе на удивление в нашем смысле пришлось “натягивать” глаз на ж(цензура), чтобы получать более менее трактуемые данные…
Это пожалуй была для нас наиболее трудоемкая часть - подумать/придумать.
Хотелось бы уметь расширять репорты, но еще этого нету, и ограничено очень сильно лицензионными соглашениями чартов.
В планах таки попробовать интеграцию с графитом (чтобы видеть корреляцию с системой) или с другой мониторинг системой. На данный момент, смотрю под jconsole, что происходит с jvm при нагрузке.
testomat.io управление авто тестами
Но на вики там довольно подробно описано, что он может, а что нет
, которое значительно понижает входной барьер в gatling. Огромный респект разработчикам.