Pull to refresh

Comments 7

Меня не устраивают внешние системы, поэтому использую самописный (как верно подмечено в статье) рой.
Диспетчер получает на вход пачку access.log файлов проекта из прода и исходя из настроек, формирует «ульи» (пакеты) пчел, в каждом из которых свои настройки: задержка между реквестами, равномерность задержки (случайное число в диапазоне или константа), а также такие фишки как поддержка сессии, фильтрация урлов из пакета заданий, получение и парсинг полученного хтмл или игнорирование тела ответа. «Пчелы» же пишутся под конкретные нужды, хотя после пары десятков испытаний, уже есть набор, который покрывает основные нужды. И все сделано практически на голой Java 1.7.
Главный минус моего решения — это кол-во VPS, которые используются для стресс теста. 2..3 — мало для 100% имитации полноценной нагрузки. В этом плане, описанные в статье системы конечно имеют фору.
PS: Зато они не могут нагрузить тестовый стенд онлайн траффиком с прода через зеркалирование в nginx :)

Не хватает Яндекс.Танка, мне кажется

Когда нужно нагрузить REST API, нет проблем с выбором инструментов. Вот когда появляется что-то менее тривиальное (GRPC, собственный протокол над websocket, etc), приходится искать плагины или писать свои расширения к существующим инструментам, если они это поддерживают. Доводилось попробовать:
— Gatling. Хороший инструмент, но для его расширения нужно знать Scala и разобраться в плохо задокументированных исходниках.
— Locust. Расширять удобно (python), но как нагрузочный инструмент слаб — не удавалось по-настоящему нагрузить, выше 1к ops не поднимались.
— Яндекс.Танк + Pandora. Остановились на этой связке — относительно простой и легко расширяемый инструмент (плагин на Go), который с одной стороны дает предсказуемую нагрузку, а сдругой стороны умеет агрегировать и строить хорошие отчеты, плюс возможность выгрузки в Influx с последующей визуализацией.
Использовал K6 для проверки сервисов под нагрузкой от нескольких одновременных клиентов, очень удобно. Но огорчило отсутствие нормальной возможности запуска сразу нескольких генераторов нагрузки (ну там раскидать нагрузку по воркерам, синхронизировать пулы данных и тд), правда там есть удаленное API, так что просто инициализировал воркеры в приостановленном режиме и запускать (условно)одновременно с отдельной машины по API.

Зато написанные скрипты с проверками можно в дальнейшем для автотестов API использовать.

Напишите статью про вчерашний казус, кто пострадал, причины, следствия и кто виноват)

Sign up to leave a comment.