Тестування ємності (Capacity testing)
Тестування потенційних можливостей (capacity testing): Тип тестування рівня продуктивності з метою оцінки рівня, у якому зі збільшенням навантаження (числа користувачів, транзакцій, елементів даних, і т.д.) елемент тестування піддається загрозі не забезпечувати необхідну продуктивність. (ГОСТ 56920)
Capacity – базовий тест, який зазвичай виконується першим. Усі наступні тести на середній час відповіді, регенерацію системи, утилізацію ресурсів потрібно виконувати з огляду на результати Capacity.
Тестування ємності гарантує, що додаток та середовище можуть безперешкодно обробляти максимальну кількість користувачів або транзакцій відповідно до вимог продуктивності, визначених у вашій угоді про рівень обслуговування (SLA). Тестування ємності націлене на тестування максимальної ємності вашої системи з точки зору трафіку, забезпечуючи при цьому оптимальну взаємодію з користувачем. Загальні приклади продуктивності SLA включають час завантаження домашньої сторінки, час відповіді веб-сторінки, тривалість транзакції (наприклад, час входу в обліковий запис, час пошуку та платежу). Загальна мета полягає в тому, щоб ідентифікувати «зону безпеки» системи та утримувати її максимально можливою мірою. Тестування ємності допомагає визначити,
Місткість системи вимірюється в rps (requests per second). Використовуваний підхід: поступово підвищуємо навантаження до моменту, коли час відповіді почне зростати експоненційно. Експоненційне зростання часу відповіді, як правило, пов'язане з повною утилізацією одного з ресурсів, через яке запити замість миттєвої обробки вишиковуються один за одним і чекають своєї черги на обробку.
Зверніть увагу: від 1 до 12 rps процент часу відповіді практично не змінюється. Тільки на 13 і 14 rps ми бачимо незначне зростання, яке не змінюється з часом. Це означає, що ми практично вичерпали ресурс, який упремося, але черга ще не утвориться. На 15 rps час відповіді почав зростати експоненційно, отже, це і є наша межа. Таким чином, можна дійти невтішного висновку, що ємність =14 rps. Наступний крок - пошук ресурсу що вичерпався та не дає системі обробляти більше 14 rps.
Capacity point - точка, де перестає зростати пропускну здатність і збільшується час відповіді.
Виходячи з цього тестування вибираються значення для stress, load та soak/endurance тестів. Для stress береться значення близьке до capacity point, але трохи менше. Для load кількість користувачів із зони деградації.
Важливо, ваша мета - не отримати кількість rps, при якому все вибухає, а зрозуміти, який саме ресурс стане вузьким місцем при підвищенні навантаження. Тому, якщо сервер, що обстрілюється, не покритий моніторингом - можете навіть не починати тест. Загальний підхід до збору телеметрії - що більше метрик збирається, то краще. Почати варто з мінімального набору:
Основні фізичні, функціональні компоненти сервера (залізо): процесор, пам'ять, мережа, жорсткий диск.
Метрики операційної системи: переривання, перемикання контекстів, середнє значення завантаження системи за 1, 5 та 15 хвилин.
Метрики програмного забезпечення на сервері.
По можливості постарайтеся визначати, у яких пропорціях ресурси використовуються вашим програмним забезпеченням.
Джерела:
Дод. матеріал:
Last updated