goader — консольный бенчмарк с простой конфигурацией и поддержкой различных бэкендов для тестирования
Название происходит от go и loader, а также имеет свое значение на английском, "подгонять копьем, палкой"
На данный момент можно тестировать (аргумент -requests-engine):
- http (GET запросы либо GET+PUT)
- disk
- s3 (С авторизацией по ACCESS/SECRET keys, endpoint необходим, но это дает возможность проверять private s3, signature ver4 на данный момент не поддерживается, но планирую)
- null и sleep для тестирования самого бенчмарка
Уклон сделан на запись и считывание файлов, не страничек
Пример использования
goader -rps=300 -wps=150 -min-body-size=1 -max-body-size=128k --max-requests=1000 -requests-engine=disk -url=tmp/NN/RRRRR
Точки появляются в реальном времени в соответствии с каждым запросом, мне в свое время это позволило визуально выявить проблемы, в том случае, что цифры мало что дали бы. В случае ошибок на их месте будет E
Существует немало утилит для нагрузочного тестирования, но лично у меня к ним ряд претензий, что и сподвигло написать свой...
Проблема номер 1, что мы тестируем?
Упор на “кол-во параллельных тредов”, поиск максимальной нагрузки, максимального кол-ва тредов. Либо фиксированное кол-во тредов
Это конечно здорово, но лично у меня, в реальной жизни, при замене какого либо компонента системы достаточно редко возникал именно этот вопрос, сколько же оно потянет. При замене компонентов куда чаще вопроса два и они другие:
а) Отклик при заранее известной нагрузке. Как например 50 PUT/s, 300 GET/s. Проверяем время отклика на старой и новой системе. От замены компонентов кол-во пользователей не вырастет, цель как правило — улучшить отзывчивость системы
goader -rps=300 -wps=50 -min-body-size=1 -max-body-size=128k -requests-engine=upload -url=http://localhost/files/user_NNNNN/file_RRRRб) Мы все таки хотим дать больше, чем было, хотим знать максимум системы. Опять таки, что это такое? Кол-во клиентов которые сервер может выдержать? Кол-во параллельных клиентов которые получают Н-ый процент ошибок? Очень часто ошибок нет, а просто получаем огромное время отклика.
Поэтому для себя максимум системы я определил как “кол-во параллельных клиентов, при котором время отклика не превышает заданное значение"
goader -rpw 2 -max-latency 5ms -requests-engine=disk -url=tmp/RRRRRRR -body-size=4k -max-requests=30000Нагрузка выравнивается по WRITE-ам (PUT/WriteFile), кол-во READ-ов установлено относительно WRITE-ов, т.е reads-per-write, чтений на запись — в примере 2, может быть дробным числом
Кол-во тредов будет адаптироваться под задержки и на выходе получим число одновременных клиентов которые мы можем выдержать с данной загрузкой. Опционально максимум можно ограничить-увеличить аргументом -max-channels, по дефолту 32
Традиционное “кол-во одновременных клиентов” так же существует, -wt=5 -rt=10 (5 тредов на запись, 10 на на чтение)
Это 2 режима, которых мне не хватало. Но была у проверенных мной бенчмарков еще проблема номер 2
Сложность конфигурации
Дополнительным требованием, выставленным себе, было отсутствие UI и файлов конфигурации.
Это конечно очень круто когда настроек миллион и возможности безграничны, но для этого нужна еще одна мощная машина, UI, пол дня на написание конфигурации и потом таскать эти файлы за собой. Безусловно, иногда это все таки плюс, мне было важно иметь возможность подключиться на любой из серверов и иметь возможность запустить, в ручную, по памяти тест системы. Либо послать сотрудникам в слеке короткое сообщение с командой, а дальше они все сделают сами. В крайнем случае подсмотрят в goader --help и опять таки доделают все сами.
Пока что, удается обходиться без файлов конфигурации, и я надеюсь так это и оставить
Например, зачастую, список путей предоставляется отдельным файлом. Альтернатива: -url=http://127.0.0.1/user/NNNN/images/RRRRRRR.jpg
NNNN — будет заменено случайными числами
RRRRRRR — будет заменено случайными буквами
XXXXX — будет заменено последовательно увеличивающимися числами
Наглядность
Цифры цифрами, а порой глазами можно увидеть аномалии, которые сложно увидеть цифрами, не зная что искать
Каждый запрос отображается в консоли точкой(зеленая — чтение, синяя — запись), ошибка E, смена кол-ва тредов стрелкой вверх либо вниз.
Эта функция позволила найти нам проблемы в системе, так как мы смогли визуально увидеть, как просела производительность в определенный момент.
Помимо этого, конечный результат так же стремится быть лаконичным и информативным. Есть возможность заменить его на json, -output=json/human
Порой точки мешают, их можно отключить -show-progress=false
При большом кол-ве запросов, либо при удаленном исполнении, глазами бывает трудно увидеть прогресс, для этого есть экспериментальная функция создания html файла с визуальным отображением (-timeline-file=timeline.html), когда запрос вышел и сколько времени он занял. Есть планы по улучшению, сменить отображение времени жизни запроса на вертикальное и тогда будет куда более наглядно, в какое время сколько запросов существовало. Но пока что это не приоритет
Поддержка простых http запросов
Под простыми я подразумеваю только GET-запросы к страничками, без PUT-ов используя все вышеописанное
Это не было приоритетом, но использовать можно
Запросов в секунду
goader -rps=300 --max-requests=1000 -url=http://localhost/user/NN/product/RRRRКол-во одновременных клиентов
goader -rt=32 --max-requests=1000 -url=http://localhost/user/NN/product/RRRRПоиск максимального кол-ва одновременных клиентов с заданной максимальной задержкой
goader -wt=0 -max-latency=300ms --max-requests=1000 -url=http://localhost/user/NN/product/RRRRЛучше делать большее кол-во запросов в этом режиме, для более точных результатов
К слову, это был мой первый опыт с go, хотелось на практике проверить восторженные отзывы, не могу сказать, что я их не поддерживаю. Да, есть свои недостатки, но в целом, быстрая компиляция, быстрая проверка ошибок, единая экосистема, простая система типов — все это позволяет как модно утверждать, сконцентрироваться на коде, а не особенностях экосистемы.
А то, что, без лишней магии на выходе получаются бинарники под все системы — вообще прелесть.
На гитхаб заливаю только linux/386 linux/amd64 windows/amd64 darwin/386 darwin/amd64, но если кому то необходимо расширить этот список — то без проблема. В рамках поддерживаемого самим golang-ом
Комментарии по поводу самого кода тоже приветствуются
Скачать можно с https://github.com/tigrawap/goader/releases либо собрать самим, лицензия MIT
Для удобства использования лучше положить в $PATH
Автор: TigraSan
