goader — консольний бенчмарк з ухилом на запис-читання файлів

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

image
Точки з'являються в реальному часі у відповідності з кожним запитом, мені в свій час це дозволило візуально виявити проблеми, в тому випадку, що цифри мало що дали б. У разі помилок на їх місці буде 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-му. Коментарі з приводу самого коду теж вітаються.
Завантажити можна з Github або зібрати самим, ліцензія MIT. Для зручності користування краще покласти у $PATH.
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.