Модель навантаження: профіль, сценарії, think time

Що таке модель навантаження і чому «50 тисяч користувачів на день» ще не є моделлю?

Модель навантаження — це набір рішень, які роблять прогін відтворюваним і осмисленим: які операції виконуються, з якою інтенсивністю, з якими паузами між діями, за якою формою в часі і що саме зафіксовано в інструменті. Бізнесова цифра про кількість людей за добу не відповідає на жодне з цих питань, тому підставити її як кількість віртуальних користувачів (virtual users) — це не переклад, а підміна. Ті самі 50 тисяч можуть рівно розмазатися по добі, а можуть зібратися у двогодинне вечірнє вікно; кожен з них може зробити один запит, а може сорок. Різниця в тому, що реально прилетить у систему, тут вимірюється десятками разів у будь-який бік. Найнеприємніше, що помилка в моделі не червонить тест: прогін завершується успішно, звіт має пристойний вигляд, а система складається на першому ж справжньому піку. Тому правильна реакція на «перевір, чи витримаємо» — не запуск інструмента, а збір профілю.

Що таке операційний профіль і які дані для нього збирають?

Операційний профіль (operational profile) описує, як компонентом чи системою користуються насправді або як планують користуватися: хто саме звертається до застосунку і що робить. Збирають для нього дві речі. Перша — типи персон і ролі: анонімний відвідувач, зареєстрований учасник, адміністратор, групи з розширеними правами; поведінка в них різна за складом операцій і за вартістю кожної операції для бекенду. Друга — оцінка того, скільки людей припадає на кожну роль чи задачу за одиницю часу впродовж періоду, який ми розглядаємо; саме це число потім стає основою профілю навантаження. Профілів у одного застосунку зазвичай кілька — по одному на патерн взаємодії, — і потрібне навантаження дістають їхньою комбінацією. Важлива деталь, яку часто пропускають: взаємодія буває не тільки людською, тож нічні пакетні джоби й обмін даними між системами теж мають власні профілі й теж навантажують ту саму базу.

Звідки ви візьмете профіль для системи, якої ще немає в проді?

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

З яких складників будують профіль навантаження?

Профіль навантаження (load profile) описує активність, якої система може зазнати на проді: певна кількість екземплярів виконує дії заздалегідь визначених операційних профілів протягом заданого періоду. Коли ці екземпляри — люди, їх називають віртуальними користувачами. Щоб профіль був реалістичним, потрібні чотири речі: ціль перф-тесту, операційні профілі, які точно відтворюють окремі патерни використання, знання наявних проблем із пропускною здатністю (throughput) та конкурентністю (concurrency), і нарешті кількість екземплярів разом із їхнім розподілом у часі. Порядок у цьому переліку не випадковий: першою стоїть ціль, а не число користувачів. Профіль під питання «чи переживемо розпродаж» і профіль під питання «де в нас вузьке місце» різні навіть на тій самій системі, бо в них різні критерії успіху. Кандидат, який починає опис профілю з кількості потоків, фактично зізнається, що ціль у нього не сформульована.

Що в перф-тестуванні називають «сценарієм»?

Це той випадок, коли знайоме слово в перф-контексті означає зовсім інше, і на підміні регулярно ловлять. У функціональному сценарій — послідовність кроків одного користувача; у навантажувальному сценарієм зазвичай називають результат агрегування операційних профілів, тобто весь профіль навантаження разом із кількістю екземплярів і розкладом їхньої появи. Практичний наслідок: коли колега каже «у нас три сценарії», він, найімовірніше, має на увазі три паралельні потоки навантаження зі своїми міксами й розкладами, а не три скрипти. Інструменти закріплюють саме це значення: k6 дозволяє оголосити в одному скрипті кілька сценаріїв, і кожен запускає власну функцію за своїм розкладом користувачів та ітерацій, який задає його екзекʼютор. Тому коректне питання до чужого тесту звучить як «які сценарії й у яких пропорціях», а не «який у вас скрипт».

Які канонічні форми розподілу навантаження в часі ви знаєте?

Їх чотири. Ramp-ups — рівномірне зростання, скажімо плюс один віртуальний користувач щохвилини. Ramp-downs — дзеркальне рівномірне зменшення. Steps — стрибкоподібні зміни, наприклад плюс сотня користувачів кожні пʼять хвилин. І четверта, яку згадують рідше за всіх, — заздалегідь визначені розподіли, де обсяг повторює денний або сезонний бізнес-цикл. Плутати першу з третьою не варто: наростання рівномірне за означенням, а кроки — це серія миттєвих змін. Загальна ж настанова від інструментальної практики — тримати форму простою: напрямків «нагору, плато, вниз» вистачає всім видам тестів, а профілі-«гірки» з кількома підйомами й спадами лише марнують час і роблять результати непорівнюваними.

Що таке think time і чи входить він у час відповіді?

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

«Приберемо think time, щоб тест був жорсткішим» — що ви відповісте?

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

Постійна пауза чи випадкова — що брати в скрипті?

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

Як перевірити готовність до сезонного піку — окремим стрес-тестом?

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

Як зібрати мікс: фонове навантаження плюс основний сценарій?

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

Як обрати період наростання і що робити з його метриками?

Період наростання (ramp-up) задає, за скільки часу інструмент виведе всі потоки в роботу: десять потоків із періодом у сто секунд означають, що кожен наступний стартує на десять секунд пізніше за попередній. Критерій довжини двобічний, і саме це відрізняє продуману відповідь від завченої. Знизу: період має бути достатньо довгим, щоб система не отримала неспланований удар на самому старті прогону. Зверху: достатньо коротким, щоб останні потоки увійшли в роботу раніше, ніж перші її завершать, — інакше цільового навантаження не буде взагалі ніколи, хоча в конфігурації стоїть потрібне число. Як стартову евристику радять брати період, що чисельно дорівнює кількості потоків, а далі коригувати за фактом. Друга частина відповіді — про звіт: показники, зібрані під час наростання, до підсумку по плато не додають, бо навантаження там ще не цільове, а холодні кеші й порожні пули зʼєднань дають нетипово погані часи відповіді. Спадання теж не декорація — на ньому видно, чи повертається система до нормальних показників після навантаження.

Чим pacing відрізняється від think time?

Відрізняються вони двома речами: де стоїть пауза і що вона регулює. Час на роздуми живе всередині сценарію, між сусідніми діями, і потрібен для правдоподібності поведінки; темп ітерацій (pacing) — це пауза після завершення транзакції чи сесії, і призначення в неї інше: витримати задану частоту транзакцій, тобто керувати самим навантаженням. Зріла відповідь додає ще одну річ: вендоронезалежного означення в темпу немає. Силабус ISTQB CT-PT такого поняття не вводить взагалі — він говорить лише про час на роздуми, — а означення дають довідки інструментів, кожна під власну реалізацію. У Silk Performer пауза додається до часу транзакції так, щоб сума дорівнювала цільовому часу сесії, і при сповільненні сервера інструмент сам зменшує паузу; Gatling подає темп окремим типом паузи в DSL — «раз на пʼять секунд незалежно від того, що всередині». У JMeter той самий механізм є, але слова pacing у документації немає. Тому на співбесіді безпечно спершу назвати різницю по суті, а вже потім уточнити, у чиїй термінології ви говорите.

«Ціль темпу — 100 транзакцій за хвилину». Чому цього формулювання мало?

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

Чим відкрита модель відрізняється від закритої і як обрати між ними?

У закритій моделі (closed model) нова ітерація віртуального користувача стартує лише після того, як завершилася попередня, — популяція фіксована, і поки всі зайняті очікуванням відповіді, нових звернень не зʼявляється. У відкритій (open model) нові користувачі приходять за власним розкладом незалежно від того, скінчили попередні чи ні. Розрив у тому, що типове налаштування тесту закрите, а типова публічна система відкрита: живим людям байдуже, що попередні відвідувачі ще чекають на сторінку. Практичне правило просте: вимога, сформульована в запитах за секунду, вимагає відкритої моделі, бо тільки в ній фіксується швидкість приходу; а вимогу, сформульовану в одночасних користувачах, закрита модель обслуговує нормально. Інструментально межа проходить по тому, що зафіксовано: constant-vus і ramping-vus тримають кількість користувачів, constant-arrival-rate і ramping-arrival-rate — кількість ітерацій за період, і у відкритих екзекʼюторів зʼявляється пул попередньо виділених користувачів. Тому чужий перф-звіт починають читати з питання про модель: доки на нього немає відповіді, цифри всередині не інтерпретуються.

Що таке coordinated omission і чому через нього закрита модель не годиться для вимоги в RPS?

Це ефект, за якого тест сам зменшує навантаження рівно тоді, коли систему треба тиснути. Механіка прямо випливає з означення закритої моделі: старт наступної ітерації привʼязаний до завершення попередньої, отже швидкість появи нових запитів залежить від часу відповіді системи. Арифметика наочна — якщо запит виконується близько шести секунд, один віртуальний користувач дає одну ітерацію на шість секунд, тобто десять за хвилину, і жодного способу подати більше в нього немає. Щойно система під тиском починає гальмувати, ітерації подовжуються, частота падає, і тест слухняно чекає замість того, щоб тримати задану інтенсивність. Наслідок для звіту простий: у момент, коли цікаво найбільше, прогін подає менше запитів, ніж стояло в плані, — і цифри описують уже інший тест. Саме тому мета «симулювати певну швидкість приходу» чи «певну пропускну здатність» закритою моделлю недосяжна — там навантаження задає система, а не ви.

Чим ramping-vus відрізняється від ramping-arrival-rate?

Це не два способи написати те саме, а два різні тести з однаковим на вигляд графіком. ramping-vus нарощує кількість віртуальних користувачів: кожен виконує стільки ітерацій, скільки встигне, тож фактична частота запитів залежить від часу відповіді системи. ramping-arrival-rate нарощує саму частоту ітерацій: розклад приходу заданий заздалегідь і від поведінки системи не залежить, а користувачі беруться з попередньо виділеного пулу. Коли система здорова, обидва графіки можуть виглядати схоже; коли починається деградація, вони розходяться радикально — у першому випадку навантаження просідає само собою, у другому продовжує тиснути, і ітерації накладаються одна на одну. Звідси й вибір: перевіряєте поведінку за N одночасних користувачів — беріть перший, маєте вимогу в запитах за секунду — тільки другий.

«У нас тисяча користувачів. Скільки це буде запитів за секунду?»

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

Чому кількість користувачів узагалі погана міра навантаження, а «запитів за секунду» теж може ввести в оману?

Навантаження на систему задає пропускна здатність, а кількість одночасних користувачів підставляють замість неї просто тому, що це число легше дістати і саме його просить інструмент. Без операційних профілів воно не міряє нічого: пʼятсот користувачів, які роблять короткий запит щохвилини, дають тридцять тисяч запитів за годину, а ті самі пʼятсот з тим самим запитом раз на годину — рівно пʼятсот. Різниця шістдесятикратна, і настільки ж різними будуть вимоги до заліза. Але й перехід на запити за секунду не закриває питання остаточно, бо будь-яка така цифра усереднена за вікном виміру. Система, що видає 200 запитів у парні секунди й мовчить у непарні, за середнім не відрізняється від рівної сотні — але її миттєве навантаження вдвічі більше за середнє. Тому в зрілому звіті поряд із цифрою стоїть вікно, за яким її усереднили.

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

Кейс 1. Із «50 тисяч користувачів на день» у профіль навантаження

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

Далі — проста арифметика, яка й перетворює таблицю на конфігурацію:

9 000 сесій за годину            = 2,5 сесії за секунду
2,5 сесії/с × 12 запитів         = 30 запитів за секунду  ← цільова пропускна здатність
VU = 30 × (0,2 с + 10 с)         ≈ 306 віртуальних користувачів (закрита модель)

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

• Наївне прочитання тікета помиляється у 160 разів. 50 000 у полі потоків проти 306, які реально відтворюють піковий трафік, — це не похибка, а інший тест: перше покладе стенд ще на наростанні й нічого не виміряє. Три числа, які тут злиплися в одне, — зареєстровані, активні за добу й одночасні — треба розділяти вголос, бо в бізнес-розмові вони звучать однаково.
• Мікс операцій важить не менше за кількість. Дві сотні читань каталогу і дві сотні оформлень замовлення дають різне навантаження на базу, черги й платіжний шлюз. Тому в профіль іде розподіл у відсотках, а не «типовий користувач».
• Пауза в 10 секунд — теж вимірювана величина, а не константа зі стелі. Вона взята зі спостережень і прямо входить у розрахунок кількості користувачів: змініть її на 2 секунди — і на ту саму цільову частоту вистачить близько 66 користувачів замість 306.
• Рядок про нічну переіндексацію — не формальність. Навантаження створюють не лише люди: пакетні джоби й міжсистемний обмін мають власні профілі, і на них теж треба відповісти, чи витримаємо, коли вони збігаються з піком.
• Профіль показують стейкхолдерам до прогону, а не після. Рецензія коштує однієї короткої зустрічі й захищає від найдорожчого результату — бездоганно виміряного не того, що потрібно бізнесу.

Кейс 2. Один графік, два різні тести: закрита і відкрита модель

Беремо піковий профіль з кейсу 1 і вимогу до нього: витримати 30 запитів за секунду з 95-м перцентилем не гірше 800 мс. Нижче — дві конфігурації k6 з однаковим на вигляд графіком (пʼять хвилин угору, двадцять на плато, пʼять униз). Тільки одна з них справді перевіряє цю вимогу. Одна ітерація в обох — дія користувача плюс його пауза, тобто близько 10,2 секунди на здоровій системі.

// Закрита модель: фіксуємо КІЛЬКІСТЬ користувачів
export const options = {
  scenarios: {
    peak_users: {
      executor: 'ramping-vus',
      startVUs: 0,
      stages: [
        { duration: '5m', target: 306 },
        { duration: '20m', target: 306 },
        { duration: '5m', target: 0 },
      ],
    },
  },
};

// Відкрита модель: фіксуємо ЧАСТОТУ ітерацій
export const options = {
  scenarios: {
    peak_rate: {
      executor: 'ramping-arrival-rate',
      startRate: 0,
      timeUnit: '1s',
      preAllocatedVUs: 400, // пул, з якого беруть виконавців ітерацій
      stages: [
        { duration: '5m', target: 30 },
        { duration: '20m', target: 30 },
        { duration: '5m', target: 0 },
      ],
    },
  },
};

Поки система здорова, обидва прогони виглядають однаково. Різниця вилазить у момент, коли час обробки одного запиту зростає з 0,2 до 2 секунд:

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

• Закрита модель зменшує тиск саме тоді, коли треба тиснути. Старт нової ітерації привʼязаний до завершення попередньої, тож повільніші відповіді автоматично означають рідші запити. Вимогу «30 за секунду» такий прогін не перевіряє ніколи: він перевіряє, що вміє система при 306 користувачах, а це інше питання.
• Це і є coordinated omission. Швидкість приходу нових ітерацій згасає рівно тоді, коли система гальмує: замість цільових 30 запитів за секунду прогін подає 25 — і звіт описує вже не ту вимогу, яку взялися перевіряти.
• preAllocatedVUs — не косметика. Це пул, з якого відкритий екзекʼютор бере виконавців ітерацій, і потреба в них рахується тією самою арифметикою: на 30 ітерацій за секунду при тривалості ітерації 12 секунд треба близько 360 користувачів, а не 306, яких вистачало на здоровій системі.
• Однаковий графік у звіті нічого не доводить. Дві картинки «нагору, плато, вниз» можуть означати два різні тести, тож перше питання до чужого перф-звіту — не «скільки користувачів», а «що було зафіксовано».

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

export const options = {
  scenarios: {
    background_browsing: {
      executor: 'constant-vus',
      vus: 100,
      duration: '30m',
      exec: 'browseCatalog',           // своя функція
      tags: { scenario: 'background' }, // свій тег для розбору звіту
    },
    peak_rate: {
      executor: 'ramping-arrival-rate',
      startTime: '5m',                  // сценарії йдуть паралельно; зсув задають явно
      startRate: 0,
      timeUnit: '1s',
      preAllocatedVUs: 400,
      stages: [
        { duration: '5m', target: 30 },
        { duration: '20m', target: 30 },
      ],
      exec: 'peakFlow',
      tags: { scenario: 'peak' },
    },
  },
};

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

Кейс 3. Паузи: те саме число користувачів, навантаження в сотні разів різне

Колега приносить результат: «прогнали тисячу віртуальних користувачів, усе зелене». Перш ніж вірити, треба спитати про паузи, бо вони входять у розрахунок пропускної здатності нарівні з часом обробки. Ось та сама тисяча за різних значень паузи (час обробки скрізь 0,2 секунди):

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

// скільки віртуальних користувачів треба, щоб дати задану частоту в закритій моделі
export function vusForThroughput(
  targetRps: number,
  processingSec: number,
  thinkTimeSec: number,
): number {
  return Math.ceil(targetRps * (processingSec + thinkTimeSec));
}

vusForThroughput(30, 0.2, 10); // 306 — те, що ми вивели в кейсі 1
vusForThroughput(30, 2.0, 10); // 360 — стільки треба, коли система вже гальмує

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

• Прибрані паузи — законний прийом, але з обовʼязковою позначкою. Коли мета — вижати максимальну пропускну здатність, скрипт без пауз доречний; просто це вже не «тисяча користувачів», і в звіті поруч із числом має стояти «think time вимкнено», інакше наступний читач порівняє непорівнюване.
• Пауза не входить у час відповіді. Час відповіді транзакції плюс час на роздуми дає загальний час транзакції — це два різні рядки звіту. Якщо десятисекундна пауза потрапила всередину виміряної транзакції, ваш перцентиль описує терпіння користувача, а не швидкість системи.
• Постійна пауза збиває користувачів у хвилі. Однакова затримка тримає потоки синхронними: після кожної паузи вони стартують разом, і система бачить щільні сплески замість рівного потоку. Розкид (випадковий інтервал плюс постійне зміщення) прибирає цей артефакт.
• Пауза «в кінці сценарію» в JMeter спрацьовує не там, де очікують. Таймер спрацьовує перед кожним семплером, на який поширюється його область дії, тож елемент, доданий останнім, затримає старт наступної ітерації. Щоб пауза стала саме післякроковою, її чіпляють до наступного семплера або до окремого елемента керування потоком.
• Ціль темпу без бази розрахунку — не число. «100 транзакцій за хвилину» на двадцяти потоках означає і 100, і 2 000 за хвилину залежно від того, тримається ціль на кожному потоці, на групі чи на всьому плані. У звіті це уточнення коштує один рядок, а без нього результат неможливо відтворити.

Операційний профіль

• Можу пояснити, що операційний профіль (operational profile) описує фактичний або прогнозований патерн використання системи, і знаю, які дані під нього збирають: типи персон і ролі (анонім, зареєстрований учасник, адміністратор, привілейовані групи) плюс оцінку кількості користувачів на кожну роль чи задачу за одиницю часу.
• Памʼятаю три канонічні джерела даних — інтервʼю та воркшопи зі стейкхолдерами, дані про використання схожих застосунків (доступ до автоматично зібраних канон рекомендує окремо), спостереження за виконанням визначених задач, — а на живому проді додаю власну аналітику, логи й моніторинг.
• Знаю два процесні правила побудови: згори вниз (спершу грубий широкий профіль, деталізація лише за потреби) і рецензія профілю зі стейкхолдерами до прогону; не забуваю, що навантаження створюють не тільки люди — нічні пакетні джоби й міжсистемний обмін мають власні профілі.

Профіль навантаження і сценарії

• Знаю різницю операційний профіль vs профіль навантаження (load profile): перший — що робить один патерн використання, другий — скільки екземплярів виконують ці дії та як вони розкладені в часі.
• Можу назвати чотири складники реалістичного профілю навантаження й памʼятаю, що ціль перф-тесту стоїть у переліку першою, а не кількість користувачів.
• Розумію, що «сценарій» тут означає не скрипт одного користувача, а агрегований профіль навантаження цілком — із кількістю екземплярів і розкладом.
• Знаю, що фонове навантаження закладають окремим сценарієм зі своїм профілем і своїми тегами метрик, а не додаванням користувачів у наявний.

Форма профілю: наростання, плато, піки

• Знаю чотири канонічні форми розподілу в часі (Ramp-ups, Ramp-downs, Steps, заздалегідь визначені розподіли за бізнес-циклом), не плутаю Steps із наростанням і тримаю форму простою: «нагору, плато, вниз» вистачає всім видам тестів.
• Можу пояснити, чому передбачуваний сезонний пік — це форма розподілу всередині профілю, а не привід замінити load-прогін стрес-тестом; окремим видом перевіряють раптовий сплеск.
• Знаю двобічний критерій довжини наростання (ramp-up) разом з арифметикою й евристикою «період чисельно дорівнює кількості потоків», і розумію, чому показники цієї фази не зводять із показниками плато, а спадання теж вимірюють.

Паузи: think time і pacing

• Можу пояснити, що час на роздуми (think time) — це змодельована пауза між діями всередині сценарію, і знаю межу виміру: у час відповіді вона не входить, у звіті це окремий рядок.
• Памʼятаю формулу пропускної здатності системи (кількість віртуальних користувачів поділити на суму часу обробки й паузи) і розумію наслідок: паузи змінюють подану інтенсивність за незмінної кількості користувачів.
• Знаю, чому «приберемо think time, щоб було жорсткіше» дає інший тест, а не жорсткіший, чому прийом законний лише з явною позначкою у звіті і чому випадковий таймер зазвичай кращий за постійний.
• Знаю різницю pacing vs think time (місце паузи й те, чим вона керує), даю чесну відповідь про відсутність вендоронезалежного канону в темпу ітерацій і памʼятаю, що ціль темпу без бази розрахунку неоднозначна.

Відкрита і закрита моделі

• Знаю різницю closed vs open model одним реченням і розумію, чому розрив системний: типове налаштування тесту закрите, а типова публічна система відкрита.
• Можу пояснити coordinated omission: час відповіді керує швидкістю старту нових ітерацій, тож при деградації тест сам знижує тиск — і заданої інтенсивності в прогоні вже немає.
• Знаю правило вибору моделі (вимогу в запитах за секунду тримає лише відкрита), розрізняю екзекʼютори за тим, що в них зафіксовано — constant-vus і ramping-vus проти constant-arrival-rate і ramping-arrival-rate, — і починаю читати чужий перф-звіт саме з питання про модель.

Пастка «1000 користувачів»

• Розумію, що навантаження задає пропускна здатність, і можу відтворити канонічну арифметику: 500 користувачів із коротким запитом щохвилини дають 30 000 запитів за годину, ті самі 500 раз на годину — 500.
• Знаю, що віртуальний користувач — не людина, а симуляція активностей за операційним профілем (у JMeter — потік, що виконує план цілком), і що в закритій моделі він дає один запит за час відповіді плюс паузи.
• Розрізняю три числа, які плутають в одній розмові (зареєстровані, активні за день, одночасні), і памʼятаю, що навіть «запитів за секунду» усереднене за вікном виміру.