Метрики: response time, throughput, перцентилі

Зміст

Перф-звіт — це десяток чисел на одному екрані: середній , запити за секунду, відсоток помилок, завантаження процесора. Кожне можна прочитати правильно й неправильно. Класична сцена: прогін зелений, у звіті «середній час відповіді 180 мс», а того ж дня підтримка приймає скарги на «сайт висне». Обидва твердження правдиві — просто описують різні речі.

Ця глава — про те, що саме міряє кожна метрика і чому середнє арифметичне в перф-тестуванні майже завжди бреше. Три питання — «що саме виміряно», «під яким навантаженням» і «який зріз розподілу» — закривають більшість суперечок про те, чи є проблема взагалі.

Час відповіді: одиниця виміру — транзакція

Канон ISTQB привʼязує час відповіді (response time) не до запиту, а до (transaction) — набору активностей, які система виконує від ініціації до завершення одного або кількох процесів. Саме часи відповіді транзакцій міряють, щоб оцінити продуктивність.

Різниця практична: «додати товар у кошик» — це не один HTTP-запит, і кожен окремий запит може бути швидким, а транзакція цілком — повільною. Тому транзакції ще й вкладають одна в одну: за один прогін видно і час кроку, і час процесу, а деградацію співвідносять із конкретною транзакцією.

Другу величину плутають із першою постійно — це (think time). Симульована транзакція може його включати, щоб відображати таймінг реального користувача, і канон записує співвідношення прямо: час відповіді транзакції плюс час на роздуми дорівнює загальному часу цієї транзакції.

Голе число часу відповіді не діє: канон вимагає доуточнити його часом доби, кількістю одночасних користувачів, обсягом даних. «Скільки в нас час відповіді?» — питання без відповіді.

Корисна рамка — розкладка за стейкхолдерами: час відповіді — турбота користувача, — турбота бізнесу, — турбота системи. SRE вважає запиту ключовим SLI більшості сервісів — з обмовкою, що клієнтська затримка релевантніша, а виміряти буває можливо лише серверну.

`Latency` в JMeter — це не мережева затримка

Найточніше про межі виміру говорить глосарій JMeter, бо розводить три «часи» поіменно:

величина	що саме міряється
`Elapsed time`	від моменту перед відправленням запиту до отримання останньої відповіді
`Latency`	від моменту перед відправленням до отримання першої відповіді, разом з обробкою, потрібною зібрати запит і першу частину відповіді
`Connect Time`	час встановлення зʼєднання, включно з рукостисканням SSL; із `Latency` автоматично не віднімається

Звідси три висновки. Latency в JMeter — це час до першого байта, інший предмет, ніж мережева затримка як час проходження даних між точками (її механіка — глава DNS, IP, порти та мережа). Connect Time входить у Latency і сам не віднімається, тож «сервер повільний» може означати «повільне рукостискання TLS». І JMeter не включає час рендерингу й не виконує клієнтський код, наприклад JavaScript — звідси розрив «швидкий бекенд ще не означає швидку сторінку».

Пропускна здатність системи: скільки транзакцій за одиницю часу

системи (system ) у формулюванні CT-PT — міра кількості транзакцій заданого типу, які система обробляє за одиницю часу: замовлень за годину, HTTP-запитів за секунду. Звідси й побутові RPS та TPS.

Тут є розбіжність усередині самого ISTQB. Силабус CT-PT §4.2.5 означує пропускну здатність системи через кількість транзакцій і окремо відрізняє її від мережевої пропускної здатності — обсягу даних, переміщених мережею. під тим самим терміном system throughput дає обсяг даних за заданий період, тобто те, що силабус зве network throughput. Одиниця виміру різна: транзакції проти байтів. Розділ уживає формулювання CT-PT, а наслідок простий — «пропускна здатність 200» без одиниці не означає нічого.

Навантаження задає пропускна здатність, а не кількість користувачів

Головне твердження глави канон формулює прямо: пропускна здатність системи визначає навантаження, а кількість одночасних користувачів доволі часто вживають замість неї — бо це число легше знайти і бо саме так задають навантаження інструменти. Вердикт: без , тобто без розуміння, що кожен користувач робить і наскільки інтенсивно, кількість користувачів не є доброю мірою навантаження.

Арифметика з канону робить це наочним. 500 користувачів із короткими запитами щохвилини — це 30 000 запитів за годину; ті самі 500 користувачів із тими самими запитами раз на годину — 500. Користувачів однаково, навантаження відрізняється в 60 разів, вимоги до заліза — щонайменше в 60 разів.

Канон дає й формулу:

Пропускна здатність системи = [кількість віртуальних користувачів] / ([час обробки] + [час на роздуми]).

З неї випливає неочевидний ефект: коли час обробки зростає, пропускна здатність може істотно впасти, навіть якщо все інше лишилося незмінним. Тест задає кількість користувачів і паузи, а час обробки задає система — і він росте разом із навантаженням.

Поза ISTQB метрику називають так само: SRE згадує пропускну здатність системи в запитах за секунду серед поширених SLI, а в k6 запити рахує http_reqs — разом із помилками й тривалістю вона утворює трійку .

Остання пастка — вікно агрегації: навіть «запитів за секунду» неявно агрегує дані за вікном виміру. Система, що віддає 200 запитів/с у парні секунди і нуль у решті, має те саме середнє, що й система зі сталими 100 запитів/с, але миттєве навантаження вдвічі більше.

Конкурентність і віртуальні користувачі

Конкурентність (concurrency) — міра кількості одночасних, паралельних потоків виконання; для інтерактивних систем нею може бути кількість одночасних користувачів. Глосарій ISTQB формулює вужче: одночасне виконання кількох незалежних потоків компонентом або системою.

Канон вимагає враховувати два різні аспекти робочого навантаження — пропускну здатність і конкурентність. Конкурентність представляє кількість паралельних сесій, кожна з яких може використовувати власні ресурси: навіть при однаковій пропускній здатності обсяг використаних ресурсів залежить від конкурентності. Наслідок: два прогони з однаковим RPS, але різною кількістю — це два різні тести.

Віртуальний користувач (virtual user) — не людина, а симуляція активностей, що виконуються згідно з операційним профілем користувача; конкурентність в інструментах моделюють, задаючи кількість таких користувачів. Інструментальна форма в JMeter — потік: кожен потік виконує план тесту цілком і повністю незалежно від інших, а кілька потоків симулюють одночасні зʼєднання до серверного застосунку.

Є межа, яку інструмент називає прямо: k6 попереджає, що для будь-якого сценарію не можна гарантувати, що конкретний віртуальний користувач виконає конкретну ітерацію. Зіставити VU зі значенням можна, а десятого VU з десятою ітерацією — ні. Звідси правило: привʼязуйте дані до віртуального користувача, а не до номера ітерації.

Конкурентність — ще й окремий вид тесту: перевірка ситуацій, коли конкретні дії відбуваються одночасно, наприклад коли велика кількість користувачів логіниться в один момент. Канон застерігає, що такі проблеми горезвісно важко знайти й відтворити.

Частка помилок і чому швидкі помилки «покращують» середнє

(error rate) — це саме частка, а не кількість. У k6 її тримає метрика http_req_failed типу Rate, який відстежує, як часто трапляється ненульове значення; тому поріг пишеться як rate<0.01. Канон ISTQB називає серед технічних метрик кількість помилок, що впливають на продуктивність, а SRE — частоту помилок як частку всіх отриманих запитів.

Механізм, через який ця метрика ламає всі інші, простий. Помилка зазвичай повертається швидше за успішну відповідь: сервер не робить роботи. Якщо помилкові виміри лежать у тій самій вибірці, що й успішні, вони тягнуть середній час відповіді вниз — прогін виглядає кращим саме тоді, коли система вже не працює. Канон описує цей клас загальніше: сирі результати можуть уводити в оману, і ховаються під добрими загальними числами.

Викривлення працює і в протилежний бік: якщо запит не падає швидким 500, а впирається в помилку зʼєднання, вимір дорівнює часу до зіткнення з нею — при це сам таймаут. Отже помилки псують середнє в обидва боки, і робоче правило одне — сегментувати вибірку за статусом.

Друга частина проблеми в тому, що коду відповіді мало. Дока k6 каже прямо: іноді навіть відповідь HTTP 200 містить повідомлення про помилку, і тоді варто додати перевірку тіла. Без неї прогін міряє швидкість віддавання помилки. Але й сама перевірка прогін не валить: невдалі чеки не спричиняють переривання тесту й не завершують його зі статусом провалу — k6 лише веде облік їхньої частки, і кожен чек створює rate-метрику. Щоб чек провалив тест, його треба поєднати з порогом; пороги як механізм pass/fail — тема глави про .

Канонічна таблиця метрик містить окремим рядком розкладку відповідей за кодами HTTP: вона відрізняє «система відмовляє» (5xx) від «ми неправильно приготували дані» (4xx).

Чому середнє бреше: медіана, p90, p95, p99

Означення (percentile) коротке: φ-квантиль — значення спостереження з рангом φ*N серед N спостережень; 0,5-квантиль зветься медіаною, 0,95-квантиль — 95-м перцентилем. JMeter формулює прикладніше: медіана є тим самим, що 50-й перцентиль, а 90% Line — значення, нижче за яке лежать 90% семплів.

Проти середнього арифметичного канон SRE висловлюється без помʼякшень: усереднення часів відповіді приховує важливу деталь — більшість запитів може бути швидкою, а довгий хвіст набагато, набагато повільнішим, тож метрики краще уявляти як розподіли. Приклад звідти ж: типовий запит обслуговується приблизно за 50 мс, а 5% запитів — у 20 разів повільніше; моніторинг лише за середньою затримкою не показав би жодної зміни протягом дня, тоді як хвостова затримка змінювалася істотно.

Кожен зріз відповідає на своє питання: високий перцентиль, як-от 99-й чи 99,9-й, показує правдоподібне найгірше значення, а 50-й — типовий випадок. На високому навантаженні хвіст важить дедалі більше через ефекти черг, а деякі команди SRE — спираючись на дослідження, за якими користувачі радше терплять трохи повільнішу систему, ніж систему з високою дисперсією, — дивляться лише на високі перцентилі.

Вважати розподіл нормальним теж не вийде: дані часто скошені, бо жоден запит не може відповісти швидше ніж за 0 мс, а таймаут на 1000 мс означає, що успішних відповідей понад цю межу не буде. Наслідок прямий — не можна припускати, що середнє й медіана однакові або навіть близькі.

Перцентилі не можна усереднювати

Це найважливіше практичне обмеження. Попередньо порахований квантиль не можна перерахувати під інше вікно чи інший перцентиль, а квантилі не можна агрегувати: усереднення готових квантилів із кількох інстансів дає статистично беззмістовні значення. У доці Prometheus є дослівний приклад «як не треба» — avg(http_request_duration_seconds{quantile="0.95"}) // BAD! проти правильного histogram_quantile(0.95, sum(rate(http_request_duration_seconds[5m]))) // GOOD.

Причина технічна: гістограма зберігає розподіл у вигляді, який можна агрегувати, а summary рахує квантилі всередині інструментованої програми й віддає готовими — рядок «Aggregation» для summary так і читається: Not aggregatable. Плата за агрегованість — похибка в межах ширини .

Щоб порахувати перцентиль, потрібна вся вибірка, а не два готові числа з двох :

// φ-квантиль — значення з рангом φ*N у відсортованій вибірці
function percentile(samples: number[], p: number): number {
  const sorted = [...samples].sort((a, b) => a - b);
  const rank = Math.ceil((p / 100) * sorted.length);
  return sorted[Math.max(rank - 1, 0)];
}

Скільки перцентилів називає ISTQB

Факт, який добре назвати на співбесіді: канонічна таблиця метрик CT-PT містить для часу відповіді транзакції рівно чотири зрізи, і найвищий із них — 90% Percentile. Ні p95, ні p99 ця таблиця не називає — вони приходять із практики SRE та з інструментів. У k6 для метрик типу Trend доступні агрегації avg, min, max, med і p(N), де N — перцентиль між 0.0 і 100, а поріг задається в мілісекундах: приклад із доки — p(90) < 300. І дрібниця, яка виглядає як хитрість, а є нормою: вісь Y на графіках затримки зазвичай роблять логарифмічною, інакше хвіст не видно.

Утилізація ресурсів: метод USE

Час відповіді й пропускна здатність кажуть, що система повільна; утилізація ресурсів (resource utilization) допомагає сказати, де саме. Найкоротша робоча методологія тут — метод USE: для кожного ресурсу перевірте утилізацію, й помилки.

термін	означення
ресурс	усі фізичні функціональні компоненти сервера — процесори, диски, шини
утилізація	середній час, протягом якого ресурс був зайнятий обслуговуванням роботи
насичення (saturation)	ступінь, до якого ресурс має додаткову роботу, якої не може обслужити — часто в черзі
помилки	кількість подій-помилок

Одразу пастка, названа в самому джерелі: в утилізації два різні означення. Друге — частка ресурсу, яку використано, і тоді 100% означає, що більше роботи прийняти не можна; у першому сенсі 100% ще не є відмовою. Одиниці теж різні: утилізацію виражають у відсотках за інтервал часу, насичення — як довжину черги, помилки — скалярними лічильниками.

Як читати значення:

100% утилізації — зазвичай ознака вузького місця, але підтвердити її треба насиченням і його ефектом.
Понад приблизно 70% уже може бути проблемою: вимір за довгий період ховає короткі сплески до 100%, а деякі ресурси, як-от жорсткі диски, не можна перервати посеред операції — після 70% затримки в черзі стають частішими.
Будь-який ненульовий ступінь насичення може бути проблемою — його міряють довжиною черги або часом очікування в ній.
Ненульові лічильники помилок варто розслідувати, надто якщо вони зростають, поки продуктивність погана.
Негативний результат теж цінний: низька утилізація, немає насичення, немає помилок — це звужує обсяг розслідування.

Ресурсами тут є не лише залізо. У мʼютексів утилізація — час утримання лока, насичення — потоки в черзі на нього; у пулів потоків утилізація — час, коли потоки були зайняті, насичення — кількість запитів, що чекають на обслуговування. Це рівно ті ресурси, які CT-PT називає причинами відмов: недостатні пули ресурсів, пули потоків, зʼєднання з базою даних.

Серед технічних метрик канон ISTQB перелічує утилізацію так: процесор, памʼять, мережева пропускна здатність, мережева затримка, дисковий простір, швидкість вводу-виводу, вільні й зайняті потоки. Окремо називає фонове навантаження на спільні ресурси — на спільному стенді ваш вимір може описувати сусіда.

Метод має й межу: він найефективніший для ресурсів, які деградують під високою утилізацією, тоді як кеші під нею продуктивність поліпшують. Автор оцінює віддачу як приблизно 80% проблем сервера за 5% зусиль — це чеклист для швидкого старту, а не заміна профілювання.

Типові помилки

«Середній час відповіді 180 мс — усе добре» → виглядає як гарантія, а насправді середнє нічого не каже про хвіст: більшість запитів може бути швидкою, тоді як 5% ідуть у 20 разів повільніше.
«Ми взяли p95 з трьох воркерів і усереднили» → виглядає як розумне наближення, а насправді це статистично беззмістовна величина: готові квантилі не агрегуються. Потрібна гістограма або сира вибірка.
«Навантаження — 500 користувачів» → виглядає як специфікація, а насправді без операційного профілю це не міра: ті самі 500 користувачів дають 30 000 або 500 запитів за годину.
«Прогін зелений, помилок 30%» → виглядає як дрібний недолік, а насправді зелень із помилок і взялася: швидкі відмови тягнуть середнє вниз, таймаути — вгору.
«У JMeter Latency 40 мс — мережа хороша» → виглядає як мережевий вимір, а насправді це час до першого байта, у який входить і Connect Time з TLS, і робота сервера.
«Процесор на 40%, ресурсів вистачає» → виглядає як здоровий стенд, а насправді довге вікно ховає секундні сплески до 100%, а вузьким місцем може бути чи лок. Канон описує рівно такий випадок: утилізація значно нижча за 75%, тоді як час відповіді ключових транзакцій на порядок завеликий.
«Додали чек на тіло — тепер тест валиться при помилках» → виглядає як гейт, а насправді невдалі чеки лише накопичують частку. Гейтом чек стає в парі з порогом.

Підсумок

Метрика без умов виміру нічого не означає. Час відповіді міряють для транзакції, а не для запиту, і доуточнюють часом доби, кількістю одночасних користувачів, обсягом даних.
Навантаження задає пропускна здатність системи, а не кількість користувачів. Ті самі 500 користувачів — це 30 000 або 500 запитів за годину. Конкурентність — друга вісь: вона змінює споживання ресурсів навіть при однаковому RPS.
Середнє — метрика для слайда. Рішення ухвалюють за розподілом: медіана дає типовий випадок, високий перцентиль — правдоподібне найгірше. Готові перцентилі не усереднюються ніколи.
Частка помилок читається разом із часом відповіді, а не після нього. Швидкі відмови занижують середнє, таймаути завищують, а 200 ще не означає успіху.
Утилізація каже «де», а не «чи погано». На кожен ресурс потрібні три числа — утилізація, насичення, помилки; ненульова черга вже є сигналом, а ресурсами є й пули потоків та локи.

Можливі питання

«Що таке response time і чим він відрізняється від latency?» — перевіряють, чи розводите три речі: час транзакції, час до першого байта і мережеву затримку. Сильна відповідь називає одиницю виміру канону — транзакцію — і згадує, що в JMeter Latency це , у який входить Connect Time.
«Чому не можна оцінювати продуктивність за середнім часом відповіді?» — слабка відповідь зупиняється на «бо є викиди». Сильна пояснює механізм: розподіл скошений, середнє й медіана можуть бути далекі одне від одного, а типовий досвід визначається хвостом, який росте через ефекти черг.
«У вас p95 = 800 мс на двох інстансах. Який p95 у сервісу?» — питання-пастка: із двох готових p95 загального не порахувати, бо квантилі не агрегуються.
«Скільки віртуальних користувачів треба, щоб перевірити 500 RPS?» — дивляться, чи попросите ви профіль, перш ніж називати число: кількість VU без операційного не задає.
«Прогін показав 12% помилок і покращення середнього часу. Що сталося?» — питання рівно про швидкі помилки. Очікують згадку, що помилкові виміри треба винести з вибірки успішних, а таймаути викривляють середнє в інший бік. Бонус — що 200 може містити повідомлення про помилку, а чек без порога прогін не валить.
«Процесор на 45%, а користувачі скаржаться. Де шукати?» — дивляться на метод: три метрики на ресурс, питання про вікно усереднення й перехід до програмних ресурсів — пул зʼєднань до БД, пул потоків, локи.

Джерела

Час відповіді: одиниця виміру — транзакція

ISTQB® CT-PT — Foundation Level Specialist Syllabus, Performance Testing v1.0 (2018) — §4.2.2: транзакція як одиниця виміру, вкладені транзакції, час відповіді плюс час на роздуми; §2.1: вимога доуточнювати метрику часом доби, кількістю одночасних користувачів і обсягом даних; §4.1.2: розкладка метрик за стейкхолдерами.
Apache JMeter — User's Manual: Glossary — Elapsed time, Latency і Connect Time, поведінка при помилці зʼєднання, межі виміру без рендерингу й клієнтського JavaScript.
Google SRE Book — Chapter 4. Service Level Objectives — затримка запиту як ключовий SLI і межа «клієнтська релевантніша, серверна вимірна».

Пропускна здатність системи: скільки транзакцій за одиницю часу

ISTQB® CT-PT — Foundation Level Specialist Syllabus, Performance Testing v1.0 (2018) — §4.2.5: означення через транзакції, відмінність від мережевої пропускної здатності, формула й арифметика прикладу з 500 користувачами; §2.1: пропускна здатність серед бізнес- і технічних метрик.
ISTQB Glossary — друге канонічне означення system throughput, через обсяг даних за період; саме воно розходиться з формулюванням силабуса.
Grafana k6 — Metrics — http_reqs як метрика запитів і трійка RED, у якій SRE впізнають три з чотирьох золотих сигналів.
Google SRE Book — Chapter 4. Service Level Objectives — пропускна здатність у запитах за секунду як поширений SLI; агрегація за вікном виміру й приклад зі сплесками 200 запитів/с.

Конкурентність і віртуальні користувачі

ISTQB® CT-PT — Foundation Level Specialist Syllabus, Performance Testing v1.0 (2018) — §4.2.5: конкурентність як друга вісь навантаження й моделювання її через кількість віртуальних користувачів; §4.2.4: термін «virtual users» для екземплярів-користувачів у профілі навантаження; §1.2: конкурентність як вид тесту й застереження про відтворюваність.
ISTQB Glossary — означення concurrency через одночасне виконання незалежних потоків і virtual user як симуляції операційного профілю.
Apache JMeter — User's Manual: Elements of a Test Plan — потік як інструментальна форма віртуального користувача й група потоків як місце, де задають їхню кількість.
Grafana k6 — Executors — відсутність гарантії «конкретний VU виконає конкретну ітерацію» і що саме з чим можна зіставляти.

Частка помилок і чому швидкі помилки «покращують» середнє

Grafana k6 — Metrics — http_req_failed як метрика типу Rate, форма порога rate<0.01 і трійка «запити, помилки, тривалість».
Grafana k6 — Checks — відповідь 200 з повідомленням про помилку, облік частки невдалих чеків і вимога поєднати чек із порогом, щоб він валив тест.
ISTQB® CT-PT — Foundation Level Specialist Syllabus, Performance Testing v1.0 (2018) — §2.1: кількість помилок серед технічних метрик; §4.1.2: розкладка відповідей за кодами HTTP у таблиці метрик; §2.4: сирі результати вводять в оману, відмови ховаються за добрими загальними числами.
Google SRE Book — Chapter 4. Service Level Objectives — частота помилок як частка всіх отриманих запитів серед поширених SLI.
Apache JMeter — User's Manual: Glossary — вимір при помилці зʼєднання дорівнює часу до зіткнення з помилкою, зокрема таймауту.

Чому середнє бреше: медіана, p90, p95, p99

Google SRE Book — Chapter 4. Service Level Objectives — середнє приховує довгий хвіст, приклад «50 мс і 5% у 20 разів повільніше», набір зрізів 50/85/95/99 і логарифмічна вісь, скошеність даних і межа «середнє й медіана можуть бути далекі», вибір високих перцентилів як практика команд.
Prometheus — Histograms and summaries — означення φ-квантиля через ранг, заборона агрегувати квантилі з дослівним прикладом BAD/GOOD, різниця гістограми й summary, похибка в межах бакета.
Apache JMeter — User's Manual: Glossary — медіана як 50-й перцентиль і 90% Line як значення, нижче за яке лежать 90% семплів.
ISTQB® CT-PT — Foundation Level Specialist Syllabus, Performance Testing v1.0 (2018) — §4.1.2: таблиця метрик, у якій найвищий названий зріз часу відповіді — 90% Percentile.
Grafana k6 — Thresholds — агрегації метрик Trend, синтаксис p(N) і межі його значень, приклад p(90) < 300.

Утилізація ресурсів: метод USE

Brendan Gregg — The USE Method — правило «утилізація, насичення, помилки для кожного ресурсу», два означення утилізації, одиниці виміру, пороги 70% і 100%, поширення методу на мʼютекси й пули потоків, межі методу й оцінка «80% проблем за 5% зусиль».
ISTQB® CT-PT — Foundation Level Specialist Syllabus, Performance Testing v1.0 (2018) — §4.1.2: розкладка «утилізація — турбота системи»; §2.1: перелік технічних метрик утилізації й фонове навантаження на спільні ресурси; §1.5 і §1.2: недостатні пули ресурсів, пули потоків і зʼєднання з БД як причини відмов.

Що таке час відповіді (response time) і до якої одиниці його правильно прив'язувати?

міряють для (transaction), а не для окремого HTTP-запиту: транзакція — це набір активностей, які система виконує від ініціації до завершення процесу. Саме часи транзакцій ISTQB CT-PT бере за основу оцінки продуктивності. Різниця не термінологічна: «оформити замовлення» — це кілька запитів, кожен з яких може вкладатися в сотню мілісекунд, тоді як увесь сценарій тягнеться три секунди. Тому транзакції роблять вкладеними: зовнішня описує процес, внутрішні — кроки, і один прогін одразу показує, який крок з'їв бюджет часу. На співбесіді відповідь «це скільки сервер думав над запитом» уже слабка — вона губить одиницю виміру й зв'язок із користувацьким сценарієм.

Що таке think time і як він співвідноситься з часом відповіді?

(think time) — пауза, яку симульована транзакція вставляє між діями, щоб таймінг сценарію нагадував поведінку живої людини, а не робота. Канон записує зв'язок арифметично: загальний час транзакції складається з її часу відповіді й часу на роздуми. Плутають ці дві величини постійно, і наслідок буває дорогий: якщо в звіті «час транзакції 8 с», а всередині сценарію сидять паузи по 3 с, реальна робота системи зайняла 5 с, і навпаки — прибрані паузи роздувають навантаження проти запланованого. Практичне правило: перш ніж порівнювати цифру з вимогою, спитайте, чи входять у неї паузи. Ще один ефект: think time стоїть у знаменнику формули пропускної здатності, тож зміна пауз змінює навантаження, навіть коли кількість не рухалась.

Чому число «час відповіді 200 мс» саме по собі нічого не означає?

Бо метрика без умов виміру не інтерпретується. Канон вимагає доуточнювати час відповіді щонайменше трьома речами: о якій порі доби міряли, скільки одночасних користувачів було в системі та з яким обсягом даних вона працювала. Ті самі 200 мс на порожній базі вночі й на бойовому обсязі в пікову годину — це різні твердження про різні системи. Тому питання «а який у нас час відповіді?» коректної відповіді не має, поки не назвали контекст. У роботі це рятує від найдешевшого спору: «у мене локально швидко» — вимір, зроблений в інших умовах, а не аргумент. Корисно тримати поруч і розкладку за стейкхолдерами: час відповіді хвилює користувача, — бізнес, — систему, тож три сторони питають про різні числа.

Що таке пропускна здатність системи (system throughput) і в чому її вимірюють?

За формулюванням CT-PT це те, скільки транзакцій одного типу система встигає обробити за одиницю часу — наприклад, замовлень за годину чи HTTP-запитів за секунду; побутові RPS і TPS ростуть саме звідси. Тут є цікава розбіжність усередині самого ISTQB: силабус означує метрику через кількість транзакцій і окремо називає мережеву пропускну здатність (network ) як обсяг даних, переміщених мережею, а під тим самим терміном дає саме обсяг даних за період. Тобто одиниця виміру в двох канонічних джерелах різна — транзакції проти байтів. Практичний наслідок один і простий: «пропускна здатність 200» без одиниці не значить нічого, і на співбесіді сильна відповідь одразу уточнює, транзакції це чи мегабіти. Поза ISTQB метрику називають так само: у SRE запити за секунду — поширений SLI, у k6 запити рахує http_reqs, і разом із помилками та тривалістю це трійка .

Замовник каже «навантаження — 500 користувачів». Чому це ще не специфікація навантаження?

Бо навантаження задає пропускна здатність, а кількість одночасних користувачів підставляють замість неї з двох побутових причин: це число легше дістати й саме ним оперують інструменти. Канон дає арифметику, після якої сперечатися нема про що: 500 користувачів, кожен з коротким запитом щохвилини, дають 30 000 запитів за годину, а ті самі 500 користувачів із тим самим запитом раз на годину — 500. Користувачів однаково, навантаження різниться в шістдесят разів, вимоги до заліза — теж щонайменше в шістдесят. Тому без , тобто без опису, що саме кожен користувач робить і як часто, кількість користувачів мірою навантаження не є. Правильна реакція на таке ТЗ — не називати число VU, а спершу попросити профіль: перелік транзакцій, їхню частоту й розподіл між типами користувачів.

Як пов'язані пропускна здатність, кількість віртуальних користувачів і час обробки?

Канон дає формулу: дорівнює кількості віртуальних користувачів, поділеній на суму часу обробки й часу на роздуми. З неї випливає ефект, який регулярно ламає плани прогонів: тест задає лише кількість користувачів і паузи, а час обробки задає сама система — і він росте разом із навантаженням. Тобто варто часу обробки збільшитися, як пропускна здатність істотно падає, хоча в конфігурації тесту ніхто нічого не змінював. Звідси типова картина: піднімаєте кількість VU, а RPS уперся в стелю або навіть поповз униз — це не помилка інструмента, це система вже деградує. Практичний висновок: цільовий RPS не «виставляють» кількістю користувачів наосліп, а перевіряють фактично досягнутий, і саме він іде у звіт.

Чим у JMeter відрізняються Elapsed time, Latency і Connect Time?

Це три різні межі виміру одного й того самого запиту. Elapsed time стартує перед відправленням запиту й зупиняється на останній отриманій відповіді — це повний час обміну. Latency закінчується раніше: на першій відповіді, тобто це фактично час до першого байта, і в нього ще входить обробка, потрібна щоб зібрати запит і прийняти першу частину відповіді. Connect Time — час встановлення з'єднання разом із SSL, і найважливіше тут те, що з Latency він автоматично не віднімається. Тому різниця Elapsed time мінус Latency приблизно описує час передавання тіла, а великий Latency при малому обсязі відповіді часто вказує або на повільне з'єднання, або на довге очікування першого байта від сервера. Плутати ці три величини дорого: питання про «response time vs latency» саме на цьому й ловить.

У звіті JMeter `Latency` 40 мс. Чи можна сказати, що мережа хороша й сторінка швидка?

Ні, обидва висновки не випливають. Latency в JMeter — це час до першого байта, а не мережева як час проходження даних між двома точками; усередину потрапляє і встановлення з'єднання разом із рукостисканням TLS, і час, який сервер витратив на початок відповіді. Тому «40 мс» може однаково описувати чудову мережу з повільним сервером і навпаки, і розділити ці випадки допомагає саме Connect Time окремою колонкою. Друга половина відповіді — про межі інструмента: JMeter не міряє час рендерингу й не виконує клієнтський JavaScript, тож він оцінює бекенд, а не сторінку. Класичний розрив саме звідси: у перф-звіті все зелено, а користувач дивиться на білий екран, поки браузер парсить і виконує бандл. Якщо потрібне сприйняття користувача, беруть браузерні виміри, а JMeter лишають для серверної частини.

Що таке конкурентність (concurrency) і чому її називають другою віссю навантаження?

Конкурентність міряє, скільки потоків виконання йде паралельно в один момент; для інтерактивних систем цю роль часто виконує кількість одночасних користувачів, а глосарій ISTQB формулює вужче — як одночасне виконання кількох незалежних потоків. Друга вісь вона тому, що робоче навантаження описують двома величинами відразу: пропускною здатністю й конкурентністю. Кожна паралельна сесія може тримати власні ресурси — з'єднання, пам'ять, стан, — тож при однаковій пропускній здатності обсяг спожитих ресурсів залежить від кількості сесій. Наслідок для планування прогонів прямий: 500 RPS від 50 віртуальних користувачів і 500 RPS від 500 віртуальних користувачів — це два різні тести, і другий може впертися в пул з'єднань там, де перший проходить чисто. Окремо конкурентність існує ще й як вид тесту — перевірка одночасних дій, наприклад масового логіну в одну секунду; канон чесно попереджає, що такі дефекти горезвісно важко зловити й відтворити.

Що таке віртуальний користувач і чому не можна прив'язувати тестові дані до номера ітерації?

Віртуальний користувач (virtual user) — не людина й не «сесія в браузері», а симуляція активностей, що виконуються за операційним профілем користувача; саме через кількість таких користувачів інструменти моделюють конкурентність. Інструментальна форма в JMeter — потік: кожен потік проганяє план тесту цілком і незалежно від інших, а кілька потоків імітують одночасні з'єднання до застосунку. Тут є межа, яку k6 називає прямо: гарантії, що конкретний віртуальний користувач виконає конкретну ітерацію, немає для жодного сценарію. Зіставити віртуального користувача зі значенням можна, а от десятого користувача з десятою ітерацією — ні. Звідси робоче правило: дані розподіляйте за номером віртуального користувача, а не за номером ітерації, інакше отримаєте плаваючі колізії — двоє беруть один акаунт, і прогін дає помилки, яких у системі немає.

Частка помилок (error rate) — це кількість чи частка, і як її задають порогом?

Це саме частка від усіх отриманих запитів, а не абсолютний лічильник — так її означує і SRE, і інструменти. У k6 її тримає http_req_failed типу Rate, який рахує, як часто трапляється ненульове значення, і поріг тому пишеться у вигляді частки, наприклад rate<0.01 для одного відсотка. Різниця з кількістю принципова при порівнянні прогонів: 2000 помилок на мільйон запитів і 2000 на десять тисяч — це різні події, хоча лічильник однаковий. ISTQB зі свого боку тримає в технічних метриках кількість помилок, що впливають на продуктивність, а в канонічній таблиці метрик під розкладку відповідей за кодами HTTP відведено окремий рядок: він і розділяє системи (5xx) та зіпсовані тестові дані (4xx). Тому в звіті корисні обидва зрізи: частка — щоб порівнювати, розкладка за кодами — щоб знати, чий це дефект.

Прогін показав 12% помилок і водночас кращий середній час відповіді, ніж минулого разу. Що сталося?

Це класика: середнє «покращили» самі помилки. Відмова зазвичай повертається швидше за успішну відповідь, бо сервер не робить роботи — не ходить у базу, не рендерить, не рахує. Якщо помилкові виміри лежать в одній вибірці з успішними, вони тягнуть середній час униз, і звіт виглядає найкраще саме тоді, коли система вже не працює. ISTQB описує цей клас загальніше: сирі результати вводять в оману, а відмови ховаються під добрими загальними числами. Викривлення працює й у зворотний бік: коли запит не падає швидким 500, а впирається в помилку з'єднання, вимір дорівнює часу до зіткнення з нею, а при — самому таймауту, тож середнє роздувається. Робоче правило одне: сегментувати вибірку за статусом і рахувати час відповіді окремо для успішних транзакцій, а читати поруч із ним, а не після нього.

Тест перевіряє лише статус-код. Чого він не побачить, і чи врятує чек на тіло відповіді?

Коду відповіді мало: дока k6 попереджає прямо — під кодом 200 цілком може приїхати текст помилки, і тоді до сценарію додають на вміст. Інакше прогін чесно виміряє, як швидко система віддає збій, і зарахує це в успіх — метрики зелені, продукт зламаний. Але сама по собі перевірка гейтом не стає: невдалі чеки в k6 не переривають тест і не роблять його статус провальним, інструмент лише веде облік їхньої частки, бо кожен чек створює власну rate-метрику. Щоб чек валив прогін, його поєднують із порогом на цю метрику — механізм pass/fail дають саме пороги. Тому сильна відповідь тут звучить так: асертити треба і код, і зміст, а рішення «червоно чи зелено» ухвалює поріг, а не сам чек.

Чому не можна оцінювати продуктивність за середнім часом відповіді?

Бо середнє замальовує довгий хвіст: більшість запитів може бути швидкою, тоді як невелика частка обслуговується в рази повільніше, і саме вона формує враження користувачів. SRE наводить показовий приклад: типовий запит іде приблизно за 50 мс, а 5% запитів — у двадцять разів довше; моніторинг лише за середньою затримкою не показав би за день жодної зміни, тоді як хвостова затримка гуляла істотно. Друга причина — форма розподілу: він скошений за побудовою, бо швидше за нуль ніхто не відповідає, а таймаут обрізає вибірку зверху. Через це припускати, що середнє й медіана однакові чи хоч близькі, не можна, а вважати розподіл нормальним — тим паче. Тому метрики читають як розподіли: медіана дає типовий випадок, високі — правдоподібне найгірше, і рішення ухвалюють за ними, а середнє лишається числом для слайда.

Що показує p50, що показує p99 і чому на високому навантаженні хвіст важить більше?

Перцентиль — це спостереження з певним рангом у відсортованій вибірці: φ-квантиль бере вимір з рангом φ×N серед N спостережень, тож квантиль 0,5 і є медіана, а квантиль 0,95 — той самий 95-й перцентиль. JMeter пояснює це прикладніше: медіана й 50-й перцентиль — одне й те саме, а 90% Line — межа, під яку потрапляють 90% семплів. Питання в кожного зрізу своє: 50-й описує типовий випадок, а високий — 99-й чи 99,9-й — правдоподібне найгірше, тобто те, що бачить найбільш невдачливий користувач. Із ростом навантаження вага хвоста збільшується через ефекти черг: запит чекає не тільки на роботу, а й на попередників. Саме тому частина SRE-команд дивиться лише на високі перцентилі, спираючись на дослідження, за якими користувачі радше стерплять трохи повільнішу систему, ніж систему з великою дисперсією. Дрібниця, що виглядає як хитрість: вісь Y на графіках затримки роблять логарифмічною, інакше хвіст просто не видно за основною масою.

«Обидва інстанси показують p95 = 800 мс. Скільки тоді p95 у всього сервісу?»

Це питання-пастка, і правильна відповідь — «із цих двох чисел загальний p95 не рахується». Готовий квантиль не можна ані перерахувати під інше вікно чи інший перцентиль, ані агрегувати: усереднення квантилів з кількох інстансів дає статистично беззмістовну величину. У доці Prometheus є навіть дослівний приклад «як не треба» — avg над рядом із міткою quantile="0.95" позначено як BAD, а правильний шлях показано через histogram_quantile над сумою rate-ів гістограми. Причина технічна: гістограма зберігає розподіл у формі, яку можна складати, а summary обчислює квантилі просто в інструментованій програмі й повертає їх готовими, тому в її документації рядок про агрегацію так і читається — не агрегується. Плата за агрегованість — похибка в межах ширини , у якому лежить квантиль. Щоб порахувати перцентиль чесно, потрібна вся вибірка або гістограма, а не два підсумкові числа з двох .

Скільки перцентилів насправді називає ISTQB і звідки тоді взялися p95 і p99?

Факт, який добре мати в кишені: у канонічній таблиці метрик CT-PT час відповіді транзакції розписано чотирма зрізами, і вище за 90% Percentile вона не піднімається. Ні p95, ні p99 там не згадані: вони прийшли з практики SRE та з інструментів, а не з силабуса. Метрики часу типу Trend у k6 дають на вибір avg, min, max, med та p(N); N тут — будь-яке число від 0.0 до 100, а сам поріг задають у мілісекундах, і приклад з доки виглядає як p(90) < 300. Знати це корисно з двох причин. По-перше, воно рятує від суперечки «за стандартом має бути p99» — стандарт цього не вимагає. По-друге, воно показує, звідки насправді береться вибір зрізу: не з підручника, а з домовленості про те, який найгірший випадок ви готові прийняти, і ця домовленість фіксується порогом.

Процесор на 45%, а користувачі скаржаться на повільність. Де шукати?

Перше — не вірити одному числу: перевіряють не утилізацію окремо, а трійку методу USE на кожен ресурс — утилізацію, (saturation) і помилки. Друге — питання про вікно усереднення: середні 45% за п'ять хвилин спокійно ховають секундні сплески до стелі, а саме в них і з'являються черги. Третє — вийти за межі заліза: ресурсом є не тільки процесор і диск, а й пул з'єднань до бази, пул потоків і локи, у яких утилізація — це час утримання, а насичення — довжина черги охочих. Канон CT-PT перелічує рівно ці речі серед причин відмов: недостатні пули ресурсів, пули потоків, з'єднання з БД. Четверте — переконатися, що ви міряєте свою систему: на спільному стенді фонове навантаження сусідів цілком може бути тим, що ви приймаєте за поведінку продукту. Показово, що сам ISTQB наводить точно такий випадок як приклад оманливих результатів: утилізація помітно нижча за 75%, а часи ключових транзакцій завеликі на порядок.

Що таке насичення в методі USE і чому 70% утилізації вже може бути проблемою?

Насичення — це ступінь, до якого ресурс має роботу, яку не може обслужити зараз; вона зазвичай стоїть у черзі, тому й міряють насичення довжиною черги або часом очікування в ній, тоді як утилізацію виражають у відсотках за інтервал, а помилки — простими лічильниками. Читається це так: 100% утилізації зазвичай вказує на вузьке місце, але підтверджувати його треба насиченням та його ефектом, а от будь-яка ненульова черга вже є сигналом. Поріг близько 70% названий окремо з двох причин: довге вікно виміру ховає короткі сплески до повної зайнятості, а деякі ресурси на кшталт дисків не можна перервати посеред операції, тож після цієї межі затримки в черзі стають частішими. Корисно пам'ятати ще й про два різні означення утилізації: як середнього часу зайнятості ресурсу, де 100% ще не відмова, і як частки використаного ресурсу, де 100% означає, що більше роботи не приймуть. І про межу самого методу: він працює для ресурсів, які під високою утилізацією деградують, а кеші під нею, навпаки, працюють краще — тож для них трійка USE читається інакше. Негативний результат теж має ціну: низька утилізація без насичення й без помилок звужує коло пошуку, а це вже прогрес у розслідуванні.

Три ситуації, у яких метрики читають неправильно й ухвалюють через це неправильні рішення: підсумкова таблиця прогону, яка виглядає прийнятною, поки не подивитись на розподіл і на помилки; сценарій k6, де рахується окремо від , а гейтом працює поріг, а не чек; і суперечка про «загальний p95» із трьох подів. Скрізь — що дивитися і чому саме це.

Кейс 1. Підсумкова таблиця прогону: п'ять чисел, які суперечать одне одному

Перф-інженер приносить зведення нічного прогону й пропонує закривати задачу: середні часи в межах вимоги, сервіс живий. Ось що в звіті:

Label       # Samples   Average   Median   90% Line   95% Line   99% Line   Error %   Throughput
Checkout       48 210    186 ms   120 ms     410 ms     980 ms    8 900 ms    11.4 %    134.2/s
Search        112 430     92 ms    70 ms     150 ms     210 ms      640 ms     0.2 %    312.8/s

CPU (app node, avg 15 min): 41 %
DB connection pool: 20 of 20 busy, avg wait queue: 37

Що дивитися і чому:

Середнє 186 мс при медіані 120 мс і p99 8,9 с — це не «трохи розкид», це скошений розподіл. Половина запитів справді вкладається приблизно у 120 мс, а найневдачливіший відсоток чекає майже дев'ять секунд. Вимога, записана на середнє, такий прогін пропустить, і саме тому рішення ухвалюють за зрізами, а не за одним числом.
11,4% помилок на Checkout роблять середнє ще й недостовірним. Відмови повертаються швидше за успіх, бо сервер не робить роботи, і в спільній вибірці вони тягнуть середнє вниз — тобто справжній час успішного оформлення замовлення гірший за 186 мс. Перше, що треба зробити зі звітом, — перерахувати часи окремо для успішних і окремо подивитися розкладку відмов за кодами HTTP: 5xx означає відмову системи, 4xx — швидше криві .
Величезний p99 при помірному p95 — підозра на . Коли запит не падає швидкою помилкою, а впирається в помилку з'єднання, вимір дорівнює часу до зіткнення з нею, а при таймауті — самому таймауту. Кругле значення в хвості (умовні 9 000 мс при таймауті 9 с) — перше, що варто звірити з налаштуваннями клієнта, перш ніж списувати його на роботу сервера.
134.2/s — число без одиниці змісту. Уточніть одразу: це транзакції Checkout за секунду чи запити, і за яким вікном усереднено. Рівні 134 транзакції щосекунди й пилка «268 у парну секунду, нуль у непарну» дають те саме середнє, але друга картина навантажує систему вдвічі сильніше в піку.
CPU 41% — не доказ здоров'я, а сусідні два рядки — доказ проблеми. Середнє за п'ятнадцять хвилин ховає короткі сплески, і головне: пул з'єднань зайнятий повністю, а середня черга по ньому — 37. Це рівно та трійка з методу USE, за якою вузьке місце видно: утилізація 100%, ненульове, і саме вони, а не процесор, пояснюють хвіст.
У звіті немає умов виміру. Скільки було , о якій порі, на якому обсязі даних — без цього таблиця не порівнюється з попереднім прогоном і не звіряється з вимогою.

Кейс 2. k6: сегментувати вибірку, задати навантаження пропускною здатністю, зробити гейт порогом

Типова помилка сценарію — покласти в одну метрику часи успішних і провалених запитів, а потім здивуватися, що прогін «покращився». Друга — вважати чек гейтом. Ось як це виглядає, коли обидві проблеми закриті:

import http from 'k6/http';
import { check } from 'k6';
import { Trend } from 'k6/metrics';

// час відповіді ЛИШЕ успішних транзакцій; true = метрика часу
const checkoutOk = new Trend('checkout_ok_duration', true);

export const options = {
  scenarios: {
    steady: {
      executor: 'constant-arrival-rate', // навантаження задаємо пропускною здатністю
      rate: 200,
      timeUnit: '1s',
      duration: '15m',
      preAllocatedVUs: 100,
      maxVUs: 400,                       // стеля конкурентності
    },
  },
  thresholds: {
    http_req_failed: ['rate<0.01'],                  // частка помилок, не кількість
    checkout_ok_duration: ['p(95)<800', 'p(99)<2500'],
    checks: ['rate>0.99'],                           // ось що робить чек гейтом
  },
};

export default function () {
  const res = http.post(
    `${__ENV.BASE_URL}/api/checkout`,
    JSON.stringify({ sku: 'A-1', qty: 1 }),
    { headers: { 'Content-Type': 'application/json' } },
  );

  const ok = check(res, {
    'статус 200': (r) => r.status === 200,
    'у тілі немає error': (r) => r.json('error') === undefined,
  });

  // помилковий вимір у вибірку часу відповіді не потрапляє
  if (ok) checkoutOk.add(res.timings.duration);
}

Що дивитися і чому:

Окрема Trend для успішних — це і є сегментація за статусом. Вбудований http_req_duration рахує все підряд, тож при зростанні відмов він покращується. Порівнювати прогони між собою має сенс лише за метрикою, у якій лежать однорідні виміри.
Чек сам прогін не валить. Невдалі чеки в k6 не переривають тест і не роблять його статус провальним — інструмент лише веде облік їхньої частки, бо кожен чек створює rate-метрику. Гейтом його робить рядок checks у порогах.
Перевірка тіла потрібна, бо 200 ще не означає успіх. Відповідь із кодом успіху цілком може містити повідомлення про помилку, і без на вміст прогін чесно виміряє швидкість, з якою система віддає збій.
constant-arrival-rate задає навантаження тим, чим його й треба задавати. Кількість користувачів навантаження не описує: ті самі 500 користувачів дають 30 000 запитів за годину або 500 — залежно від того, що і як часто вони роблять. Тут ціль зафіксована в rate — стільки ітерацій за timeUnit, — а maxVUs лише обмежує пул користувачів, з якого інструмент бере виконавців.
Формула пропускної здатності описує інший режим. «Кількість віртуальних користувачів поділити на суму часу обробки й часу на роздуми» — арифметика тесту з фіксованою популяцією користувачів, і саме там зростання часу обробки саме собою знижує . Коли навантаження задано швидкістю приходу ітерацій, темп тримає екзекʼютор, а не паузи в коді сценарію.
maxVUs — не косметика, а друга вісь. Однаковий RPS від 100 і від 400 віртуальних користувачів — два різні тести: кількість паралельних сесій змінює споживання ресурсів, навіть коли пропускна здатність та сама.
Тестові дані прив'язуйте до __VU, а не до номера ітерації. k6 не гарантує, що конкретний віртуальний користувач виконає конкретну ітерацію, тож розподіл акаунтів за ітераціями рано чи пізно дає колізії, які виглядають як дефекти продукту.

Кейс 3. «Усереднили p95 з трьох подів» — чому це число нічого не варте

У чаті релізу з'являється повідомлення: «взяли p95 з трьох подів, вийшло 1806 мс, тримаємось у бюджеті 2 с». Найпростіший контрприклад — два :

воркер	оброблено запитів	його власний p95
A	1 000	200 мс
B	10	4 000 мс

Наївне середнє дає 2 100 мс. Але 99% усіх вимірів належать воркеру A, і хвіст об'єднаної вибірки формує саме він: щоб дістатися 95-го 1 010 запитів, треба відкинути близько 50 найповільніших, а весь воркер B — це десять вимірів. Реальне значення лежить недалеко від власного p95 воркера A, тобто помилка тут не на відсотки, а в рази — і в інший бік теж: середнє готових квантилів може як завищити, так і занизити правду.

Формально причина в тому, що квантиль не адитивний: попередньо порахований зріз не перераховується ні під інше вікно, ні під інший перцентиль. У Prometheus це показано дослівно на двох рядках:

# так не можна: середнє з готових квантилів
avg(http_request_duration_seconds{quantile="0.95"})

# так можна: квантиль рахується з агрегованої гістограми
histogram_quantile(0.95, sum by (le) (rate(http_request_duration_seconds_bucket[5m])))

Різниця в : summary рахує квантилі всередині інструментованої програми й віддає готові числа, тому агрегації не піддається; гістограма зберігає розподіл по , а бакети складаються між інстансами, і вже із суми беруть потрібний зріз. Плата — похибка в межах ширини бакета, у якому лежить квантиль.

Якщо ж перцентиль рахують не з моніторингу, а зі своїх вимірів, потрібна вся вибірка — тоді зрізи чесні за побудовою:

// φ-квантиль: спостереження з рангом φ*N у відсортованому масиві
const quantile = (samples: number[], phi: number): number => {
  const sorted = [...samples].sort((a, b) => a - b);
  const rank = Math.ceil(phi * sorted.length);
  return sorted[Math.min(Math.max(rank, 1), sorted.length) - 1];
};

// правильно: спершу об'єднати виміри всіх воркерів, і лише потім рахувати зріз
const all = [...workerA, ...workerB, ...workerC];
const p95 = quantile(all, 0.95);
const median = quantile(all, 0.5); // 0,5-квантиль — це і є медіана

Що дивитися і чому:

Питання «звідки взялося це число» важливіше за саме число. Якщо джерело — три готові p95 з трьох інстансів, відповідь «загальний p95 звідси не рахується» коректна незалежно від того, наскільки красиве середнє вийшло.
Той самий закон діє для вікон часу. Годинний p95 не збирається з дванадцяти п'ятихвилинних, і «p99 за тиждень» із денних значень — так само вигадка.
Медіана і високі зрізи відповідають на різні питання. Медіана описує типовий випадок, p99 — правдоподібне найгірше; з ростом навантаження вага хвоста тільки збільшується, бо запити починають чекати в чергах, тому дивитися лише на медіану так само однобоко, як лише на середнє.
Не чекайте від таблиці CT-PT p95 і p99. Канонічна таблиця метрик доводить час відповіді транзакції максимум до 90% Percentile; вищі зрізи прийшли з практики SRE та з інструментів, а в k6 записуються як p(95) і задаються в мілісекундах.
Хвіст на графіку видно лише в логарифмічній шкалі. На лінійній осі Y кілька відповідей по дев'ять секунд перетворюють основну масу вимірів на нерозрізнювану смугу біля нуля.

Час відповіді й межі виміру

Знаю, що одиниця виміру (response time) — , а не окремий запит, і можу пояснити, навіщо транзакції вкладають одна в одну.
Можу назвати різницю між часом відповіді транзакції й часом на роздуми (think time) та формулу, за якою вони складаються в загальний час транзакції.
Пам'ятаю, що метрика без умов виміру не читається: час доби, кількість одночасних користувачів, обсяг даних.
Розводжу три різні «часи» в JMeter: Elapsed time до останнього байта, Latency до першого, Connect Time з TLS — і знаю, що останній із Latency не віднімається.
Знаю, що Latency в JMeter — це , а не мережева , і що інструмент не рахує рендеринг та не виконує клієнтський JavaScript.

Пропускна здатність і навантаження

Знаю означення пропускної здатності системи (system ) через кількість транзакцій за одиницю часу й те, що ISTQB-глосарій дає під тим самим терміном обсяг даних — тож без одиниці число неоднозначне.
Можу пояснити, чому мірою навантаження є , а не кількість користувачів, і навести арифметику, у якій ті самі 500 користувачів дають то 30 000 запитів за годину, то 500.
Пам'ятаю формулу «кількість віртуальних користувачів поділити на суму часу обробки й часу на роздуми» і наслідок: коли час обробки росте, пропускна здатність падає сама.

Конкурентність і віртуальні користувачі

Можу пояснити, чому конкурентність — друга вісь навантаження поряд із пропускною здатністю, і чому однаковий RPS від 50 і від 500 VU дає різне споживання ресурсів.
Пам'ятаю правило k6: зв'язку «конкретний VU виконає конкретну ітерацію» не гарантовано, тож розкидаю за номером , а не за ітерацією.

Помилки у вибірці

Знаю, що — саме частка від усіх запитів, а в k6 це метрика типу Rate з порогом на кшталт rate<0.01.
Можу пояснити механізм швидких помилок: повертається раніше за успіх, тож у спільній вибірці вона занижує середній час, а — навпаки, завищує.
Пам'ятаю, що 200 ще не означає успіх (у тілі може лежати текст помилки), а сам по собі чек прогін не червонить — гейтом його робить лише поріг.

Розподіл: середнє, медіана, перцентилі

Можу пояснити, чому середнє приховує довгий хвіст, і навести приклад «типово 50 мс, а 5% запитів у двадцять разів довше».
Знаю, що розподіл часів відповіді скошений (нуль знизу, таймаут згори), тож середнє й медіана можуть бути далекими одне від одного.
Розводжу питання, на які відповідають зрізи: медіана — про типовий випадок, високий — про правдоподібне найгірше, а з навантаженням вага хвоста росте через черги.
Можу пояснити, чому готові квантилі не агрегуються й не перераховуються під інше вікно, і чим гістограма відрізняється від summary у цьому питанні.

Утилізація ресурсів і метод USE

Знаю трійку методу USE — утилізація, , помилки — і одиниці кожної: відсотки за інтервал, довжина черги, лічильник подій.
Можу пояснити пороги: 100% зазвичай вузьке місце, але підтверджується насиченням, а вже понад приблизно 70% довге вікно ховає сплески й черги частішають.
Пам'ятаю, що ресурсами є й локи та пули потоків і з'єднань, а низьку утилізацію при завеликих часах ключових транзакцій канон наводить як приклад оманливих результатів — і саме там варто шукати програмний ресурс.

Знайшли помилку?

Метрики: response time, throughput, перцентилі

Час відповіді: одиниця виміру — транзакція

Latency в JMeter — це не мережева затримка

Пропускна здатність системи: скільки транзакцій за одиницю часу

Навантаження задає пропускна здатність, а не кількість користувачів

Конкурентність і віртуальні користувачі

Частка помилок і чому швидкі помилки «покращують» середнє

Чому середнє бреше: медіана, p90, p95, p99

Перцентилі не можна усереднювати

Скільки перцентилів називає ISTQB

Утилізація ресурсів: метод USE

Типові помилки

Підсумок

Можливі питання

Джерела

Що таке час відповіді (response time) і до якої одиниці його правильно прив'язувати?

Що таке think time і як він співвідноситься з часом відповіді?

Чому число «час відповіді 200 мс» саме по собі нічого не означає?

Що таке пропускна здатність системи (system throughput) і в чому її вимірюють?

Замовник каже «навантаження — 500 користувачів». Чому це ще не специфікація навантаження?

Як пов'язані пропускна здатність, кількість віртуальних користувачів і час обробки?

Чим у JMeter відрізняються Elapsed time, Latency і Connect Time?

У звіті JMeter Latency 40 мс. Чи можна сказати, що мережа хороша й сторінка швидка?

Що таке конкурентність (concurrency) і чому її називають другою віссю навантаження?

Що таке віртуальний користувач і чому не можна прив'язувати тестові дані до номера ітерації?

Частка помилок (error rate) — це кількість чи частка, і як її задають порогом?

Прогін показав 12% помилок і водночас кращий середній час відповіді, ніж минулого разу. Що сталося?

Тест перевіряє лише статус-код. Чого він не побачить, і чи врятує чек на тіло відповіді?

Чому не можна оцінювати продуктивність за середнім часом відповіді?

Що показує p50, що показує p99 і чому на високому навантаженні хвіст важить більше?

«Обидва інстанси показують p95 = 800 мс. Скільки тоді p95 у всього сервісу?»

Скільки перцентилів насправді називає ISTQB і звідки тоді взялися p95 і p99?

Процесор на 45%, а користувачі скаржаться на повільність. Де шукати?

Що таке насичення в методі USE і чому 70% утилізації вже може бути проблемою?

Кейс 1. Підсумкова таблиця прогону: п'ять чисел, які суперечать одне одному

Кейс 2. k6: сегментувати вибірку, задати навантаження пропускною здатністю, зробити гейт порогом

Кейс 3. «Усереднили p95 з трьох подів» — чому це число нічого не варте

Час відповіді й межі виміру

Пропускна здатність і навантаження

Конкурентність і віртуальні користувачі

Помилки у вибірці

Розподіл: середнє, медіана, перцентилі

Утилізація ресурсів і метод USE

`Latency` в JMeter — це не мережева затримка

У звіті JMeter `Latency` 40 мс. Чи можна сказати, що мережа хороша й сторінка швидка?