goader — консольный бенчмарк с простой конфигурацией и поддержкой различных бэкендов для тестирования. Название происходит от go и loader, а также имеет свое значение на английском, "подгонять копьем, палкой" На данный момент можно тестировать (аргумент -requests-engine): Уклон сделан на запись и считывание файлов, не страничек 
Точки появляются в реальном времени в соответствии с каждым запросом, мне в свое время это позволило визуально выявить проблемы, в том случае, что цифры мало что дали бы. В случае ошибок на их месте будет E Существует немало утилит для нагрузочного тестирования, но лично у меня к ним ряд претензий, что и сподвигло написать свой... Упор на “кол-во параллельных тредов”, поиск максимальной нагрузки, максимального кол-ва тредов. Либо фиксированное кол-во тредов. Это конечно здорово, но лично у меня, в реальной жизни, при замене какого либо компонента системы достаточно редко возникал именно этот вопрос, сколько же оно потянет. При замене компонентов куда чаще вопроса два и они другие: а) Отклик при заранее известной нагрузке. Как например 50 PUT/s, 300 GET/s. Проверяем время отклика на старой и новой системе. От замены компонентов кол-во пользователей не вырастет, цель как правило — улучшить отзывчивость системы. б) Мы все таки хотим дать больше, чем было, хотим знать максимум системы. Опять таки, что это такое? Кол-во клиентов которые сервер может выдержать? Кол-во параллельных клиентов которые получают Н-ый процент ошибок? Очень часто ошибок нет, а просто получаем огромное время отклика.  Поэтому для себя максимум системы я определил как “кол-во параллельных клиентов, при котором время отклика не превышает заданное значение". Нагрузка выравнивается по 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), когда запрос вышел и сколько времени он занял. Есть планы по улучшению, сменить отображение времени жизни запроса на вертикальное и тогда будет куда более наглядно, в какое время сколько запросов существовало. Но пока что это не приоритет. Под простыми я подразумеваю только GET-запросы к страничками, без PUT-ов используя все вышеописанное. Это не было приоритетом, но использовать можно. Запросов в секунду: Кол-во одновременных клиентов: Поиск максимального кол-ва одновременных клиентов с заданной максимальной задержкой: Лучше делать большее кол-во запросов в этом режиме, для более точных результатов. К слову, это был мой первый опыт с go, хотелось на практике проверить восторженные отзывы, не могу сказать, что я их не поддерживаю. Да, есть свои недостатки, но в целом, быстрая компиляция, быстрая проверка ошибок, единая экосистема, простая система типов — все это позволяет как модно утверждать, сконцентрироваться на коде, а не особенностях экосистемы.  А то, что, без лишней магии на выходе получаются бинарники под все системы — вообще прелесть.  На гитхаб заливаю только linux/386 linux/amd64 windows/amd64 darwin/386 darwin/amd64, но если кому то необходимо расширить этот список — то без проблема. В рамках поддерживаемого самим golang-ом. Комментарии по поводу самого кода тоже приветствуются. Скачать можно с Github либо собрать самим, лицензия MIT. Для удобства использования лучше положить в $PATH.