Як визначити ємність системи?

> Головне питання навантажувального тестування

Яка кількість одночасних запитів за одиницю часу здатна обробити ваша система без деградації за часом відповіді?

Відповідь треба шукати через тест на ємність.

> Тест на ємність

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

Ємність системи вимірюється в rps (requests per second).

Використовуваний підхід: поступово підвищуємо навантаження до моменту, коли час відповіді почне зростати експоненційно.

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

Зверніть увагу: від 1 до 12 rps процентиль часу відповіді практично не змінюється.

Тільки на 13 і 14 rps ми бачимо незначне зростання, яке не змінюється з плином часу. Це означає, що ми практично вичерпали ресурс, у який упремося, але черга ще не утворюється.

На 15 rps час відповіді почав зростати експоненційно, отже, це і є наш межа. Таким чином, можна зробити висновок, що ємність = 14 rps. Наступний крок — пошук ресурсу, який вичерпався і не дає системі обробляти більше 14 rps.

> Основні рекомендації:

1. “Більше телеметрії богу телеметрії”

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

   Тому, якщо обстрілюваний вами сервер не покритий моніторингом — можете навіть не починати тест.

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

   Почати варто з мінімального набору:

   • Основні фізичні, функціональні компоненти сервера (залізо): процесор, пам’ять, мережа, жорсткий диск.
   • Метрики операційної системи: переривання, перемикання контекстів, середнє значення завантаження системи за 1, 5 і 15 хвилин.
   • Метрики програмного забезпечення, що використовується на сервері.

   За можливості постарайтеся визначати, в яких пропорціях ресурси використовуються вашим програмним забезпеченням.

2. Налаштовуйте тестовий стенд за логікою продакшена

   Часто буває, що час зростає через дефолтні налаштування програмного забезпечення або неналаштовану операційну систему на сервері.

   Обов’язково перевірте, що всі налаштування відповідають продакшен середовищу.

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

3. Шукайте реальну причину, підтверджену логами або моніторингом

   Не робіть припущень — це не працює в навантажувальному тестуванні.

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

4. Не поспішайте підвищувати навантаження

   Намагайтеся збільшувати навантаження не частіше, ніж кожні 30 секунд. Дозвольте вашій системі попрацювати при незмінному навантаженні, щоб зняти більше телеметрії з поточного стану сервера. У подальшому це дозволить визначати, на які ресурси навантаження діє відчутніше всього.

5. Не економте на прогріві сервера

   Можна сміливо починати з 1 rps і плавно підвищувати. Дайте можливість усім вашим сервісам плавно включитися в роботу і прогріти всі кеші, плавно запустити всі необхідні процеси.

6. Не робіть великі кроки

   Якщо різко підвищувати навантаження, складно точно визначити ємність системи. Після, доведеться проводити додаткові тести, щоб з’ясувати, де саме між 500rps і 1000rps знаходиться наша точка відмови.

7. Перезавантажуйте використовуване ПЗ перед тестом, щоб зробити результати тесту відтворюваними

   Перезавантаження дозволяє скинути все важке спадщина царського режиму, яке лежить на вашому ПЗ після минулих тестів.