Словник тестування продуктивності: k6, JMeter і мова тестування навантаження
Освоєння англійської мови для тестування продуктивності — пропускна здатність, затримка p99, віртуальні користувачі, підвищення продуктивності, а також мова тестів навантаження, стресу, занурення і димових тестів.
Визначення значення: Визначення значення мови
Результати тестування продуктивності нічого не означають, якщо ви не можете їх чітко передати. Такі терміни, як «система була повільною» або «вона не могла обробляти багато навантаження» є надто неясними, щоб керувати інженерними рішеннями. Інженери продуктивності і фахівці з контролю якості використовують точний словник, який кількісно оцінює поведінку і керує відновленням. У цьому довіднику наведено основні терміни, які вам слід знати для обговорення результатів тестів продуктивності, розробки планів тестів і інтерпретації звітів англійською мовою.
Основний лексичний склад
Throughput
** Пропускна здатність ** — це кількість запитів або транзакцій, які система обробляє за одиницю часу. Зазвичай виражається як **запитів за секунду (RPS) ** або **трансакцій за секунду (TPS) **.
«При піковій завантаженості, служба розрахунку досягла пропускної здатності 1200 запитів на секунду, перш ніж час відповіді почав погіршуватися»
Латенція і перцентили
** Затримка ** — це час між моментом надсилання запиту і моментом отримання відповіді. Одне число затримки (як середнє) рідко має сенс само по собі — розподіл має значення.
** Процентильна затримка ** є більш інформаційною, ніж середні значення, оскільки вона показує досвід користувачів, на яких впливає найбільше:
- ** p50 (медійний) ** — 50% запитів виконано за цей час.
- ** p95 ** — 95% запитів виконано за цей час.
- ** p99 ** — 99% запитів виконано за цей час. « Наш SLO вимагає, щоб затримка p99 залишалася нижче 500 мс під звичайним навантаженням. »
- ** p999 (99. 9- й процентиль) ** — лише 0. 1% запитів є повільнішими за цей показник. Використовується для систем, що вимагають дуже низьку затримку хвоста.
** Затримка хвоста ** — затримка, з якою стикаються найповільніші запити, представлена у вигляді високих процентилів. Висока затримка хвоста часто вказує на суперечку за ресурси, паузи GC або шляхи холодного коду.
Точка насичення
** Точка насичення ** — це рівень навантаження, при якому ресурси системи (процесор, пам’ ять, з’ єднання) стають повністю використовуваними, а пропускна здатність або час відповіді різко збільшуються. « Точка насичення для шлюзів API була досягнута приблизно при 800 одночасних віртуальних користувачах. »
Частота помилок
** Частота помилок ** — це відсоток запитів, які повертають відповідь з помилкою (зазвичай, коди стану HTTP 4xx або 5xx). « Під час стрес- тесту частота помилок зросла з 0, 1% до 8% після того, як система перетнула межу насиченості. »
Тестування типів словникового запасу
Віртуальний користувач (VU)
** Віртуальний користувач ** — це імітований користувач у інструменті тестування навантаження, на зразок k6 або JMeter. Кожен віртуальний користувач виконує тестовий сценарій незалежно і одночасно. « Ми збільшили кількість віртуальних користувачів з 0 до 500 за п’ ять хвилин, щоб імітувати поступове зростання обсягу трафіку. »
Підйом
** Підвищення навантаження ** — це фаза на початку тесту, під час якої навантаження поступово збільшується до цільового рівня. Ramp- up уникає негайного підвищення навантаження, яке не відображає реальних шаблонів прибуття користувачів.
«Період підйому налаштований на 10 хвилин, щоб дозволити JVM розігріти свій JIT-компілятор, перш ніж ми виміряємо продуктивність у стабільному стані»
Випробування типів
** Смоук- тест ** — тест мінімального навантаження (наприклад, 1- 5 віртуальних користувачів), який виконується для перевірки правильного функціонування тестового скрипту і системи перед повним тестовим запуском. « Ми виконуємо димовий тест під час кожного розгортання, щоб виявити регресії налаштувань перед нічним тестом навантаження. »
** Тест навантаження ** — тест на очікуваний звичайний або піковий рівень навантаження, який використовується для перевірки того, чи відповідає продуктивність SLOs. « Тест навантаження виконується на 80% від нашого прогнозованого пікового навантаження протягом 30 хвилин. »
** Тест на напругу ** — тест, який перевіряє систему за межами її звичайних можливостей, щоб знайти точку переривання і спостерігати поведінку системи у разі аварії. « Тест на напругу показав, що спільний фонд з’ єднань з базою даних був першим ресурсом, який переповнився. »
** Перевірка на вміст води ** (також відома як перевірка на витривалість) — перевірка, яка виконується з тривалим рівнем навантаження протягом тривалого періоду часу (від декількох годин до декількох днів) для виявлення витоків пам’ яті, повільного виснаження ресурсів і інших проблем, що залежать від часу. « Перевірка на вміст води протягом ночі виявила витік пам’ яті у кеші сеансу, який не було видно під час 30- хвилинних перевірок. »
** Спік- тест ** — тест, який застосовує раптове, різке збільшення навантаження для імітації події « flash crowd ». « Ми запустили тест на різке збільшення, щоб перевірити, чи буде відповідати правило автоматичного масштабування до того, як час відповіді перевищить SLO. »
Мова k6 і JMeter
** Скрипт ** — у k6, файл JavaScript, що визначає тестовий сценарій. У JMeter, ** план тестування ** (файл .jmx) виконує ту ж саму функцію.
** Час роздумів ** — пауза, вставлена між запитами у скрипту віртуального користувача для імітації реальної поведінки користувача. « Без часу роздумів віртуальні користувачі працюють з API з максимальною швидкістю, що не відповідає реальним шаблонам використання. »
** Threshold ** — у k6, критерій успішності/ невдачі, застосований до метрики. « Ми встановили порог p99 < 500 мс і частоту помилок < 1%, отже конвеєр CI автоматично завершуватиме роботу, якщо швидкість знизиться. »
П’ять прикладів висловлювань
- «Розрахунки показують, що затримка p99 залишається нижче 300 мс до 600 віртуальних користувачів, але різко піднімається до 1,8 секунд на 800 користувачів, що вказує на точку насичення, що лежить близько цього порогу»
- «Ми завжди проводимо димовий тест після розгортання в стадіонарному середовищі, щоб підтвердити, що тестовий скрипт сам працює, перш ніж взяти участь у двогодинному тесті на вміст»
- «Стрес-тест виявив вузьке місце в конфігурації бази даних з’єднань — база даних закінчилася доступними з’єднаннями при 350 одночасних віртуальних користувачах»
- «Після додавання 2-секундного часу роздумів між запитами, тестовий сценарій більш точно відображав реальну поведінку користувача, а наші показники пропускної здатності стали набагато більш реальними»
- «Конфігурація порогу k6 забезпечує, що будь-яке розгортання, що погіршує затримку p95 більш ніж на 20%, автоматично не пройде ворота CI performance gate»
Повідомлення про результати
При презентації результатів тестів продуктивності зацікавленим сторонам завжди контекстуалізуйте числа. « P99 становить 480 мс » є менш корисним, ніж « затримка p99 становить 480 мс проти нашого SLO 500 мс — у нас є 20 мс запас, який ми вважаємо достатнім для поточного прогнозу трафіку, але буде потрібно переглянути перед маркетинговою кампанією в 3- ю кварталі. »
Наприклад: навігаційний пошук (навигація) — пошук інформації
Будьмо чесними, іноді найскладнішою частиною вивчення нової технічної галузі є не розуміння самих концепцій, а перекладання їх на чітку, точну англійську. Це особливо стосується співпраці з колегами з різних країн, включаючи тих, чия перша мова не є англійською. Термінологія навколо тестування продуктивності - тестування навантаження, тестування на стрес, тестування на вмивання - може бути щільною і шаруватою з конкретними значеннями, які не є відразу очевидними. Це не просто про те, щоб знати визначення; це про ефективне передання вашого розуміння, і, що найважливіше, * отримання * зворотного зв’язку точно.
Уявіть, що ви запустили димовий тест з використанням k6 для перевірки основної функціональності нової функції перед більш широким випуском. Під час перегляду коду старший інженер, Марія, залишає коментар до вашого запиту на витяг: « Підвищення відчувається трохи агресивно — я бачу деякі піки затримки біля 50- го віртуального користувача ». Якщо ви просто відповісте « Я збільшив підвищення », це, ймовірно, буде неправильно інтерпретовано. Марія не обов’ язково критикує ваше рішення; вона вказує на потенційну проблему з самою установкою тесту. Обережне формулювання відповіді є життєво важливим. Ви можете сказати: «Дякую, що повідомила про це, Марія. Я скорректував підйом до 30 секунд, щоб зменшити ці піки. Може, ви б могли розібратися, які значення затримки ви спостерігали в цей момент? Знання точних цифр допоможе мені зрозуміти вплив. “Зауважте використання таких фраз, як “флаггування цього”, “зменшення”, і запитання конкретних даних - це звичайні, професійні способи підтвердження зворотнього зв’язку і руху до рішення.
Аналогічно, коли ви описуєте результати вашого тесту навантаження у описі PR, уникайте нечітких тверджень на зразок « Система працювала добре під навантаженням ». Замість цього надайте кількісні показники: « Ми провели тест на 200 віртуальних користувачів протягом 60 хвилин, досягнувши середньої пропускної здатності 150 запитів за секунду і затримки p99 менше ніж 200 мс. Це демонструє стабільність серверних служб під тривалим навантаженням. » Використання точних термінів, таких як « пропускна здатність », « затримка p99 » і « тест на проникнення », свідчить про впевненість у ваших даних і розуміння термінології. Це також про те, щоб продемонструвати, що ви розглянули контекст результатів - що насправді означає затримка p99 для користувача?
Наконец, помни, что задавать проясняющие вопросы вполне допустимо. Якщо ви не впевнені, що хтось має на увазі під «реалістичним профілем навантаження», не вагайтеся попросити про пояснення. Завжди краще шукати пояснення, ніж робити припущення, засновані на власному розумінні термінології.
# Example k6 command demonstrating ramp-up and virtual user count
k6 run --record --out csv ./script.js --vus 50 --duration 60s --ramp-up 30sЦя проста команда k6 ілюструє ключову концепцію: параметр --ramp-up 30s контролює, наскільки швидко нові віртуальні користувачі додаються до тесту, безпосередньо впливаючи на спостережені піки затримки під час виконання тесту. Зрозуміти такі інструменти і їх налаштовувані параметри є ключовим для ефективного обміну інформацією про результати тестування продуктивності.