За часів dial-up модемів ми чекали хвилини, коли завантажиться одна сторінка сайту, і вважали це нормою. Зараз ситуація змінилася - ми не готові чекати навіть 10 секунд. Одного разу побачивши помилку на сторінці, ми знайдемо аналогічний ресурс, який працює без збоїв, а до попереднього вже навряд чи повернемося.
- Якщо ви не можете однозначно відповісти на питання:
- Чи впорається додаток з планованим потоком користувачів?
- Чи буде воно працювати, якщо кількість користувачів збільшиться?
- Яка кількість користувачів здатні витримати сервера?
- Що станеться, якщо навантаження стане більше, ніж здатні витримати сервера?
- Чи зможуть сервера відновити свою роботу і за який час, якщо кількість відвідувачів призведе до збою системи?
- Чи буде сервіс працювати також стабільно через тиждень, місяць, рік?
Саме час замислитися про нагрузочном тестуванні вашої системи або сервісу.
Чого чекають користувачі
Миттєвої роботи без збоїв і помилок. За даними дослідження компанії Akamai:
- 47% користувачів очікують, що веб-сторінка завантажиться протягом 2 секунд;
- 40% відвідувачів йдуть з сайту, який вантажиться більше 3 секунд;
- 52% стверджують, що швидке завантаження підвищує їх лояльність.
Повільне завантаження сайту підриває лояльність користувачів до компанії. це підтверджує дослідження компанії Gomez:
- в години пік 75% відвідувачів пішли на сайти конкурентів, не дочекавшись завантаження сторінки;
- 88% відвідувачів навряд чи повернеться на сайт після невдалої спроби його відкрити;
- 55% користувачів висловили менш позитивну думку про компанію в цілому, якщо сайт повільно відкривався;
- 33% поділилися негативним враженням зі знайомими.
Так що, якщо проблеми з навантаженням з'явилися, бізнес вже зазнає збитків: падає кількість користувачів, менше замовлень, більше незадоволених відгуків. Правильно розрахувати навантаження на сервіс і «залізо» потрібно заздалегідь, ще до запуску проекту.
Навантаження. Перші кроки
Отже, ви вирішили, що тестування навантаження необхідно. Нижче ми наведемо основні кроки, які допоможуть подбати про навантаженні заздалегідь.
підготовка
Думати про навантаження потрібно на етапі підготовки архітектури майбутнього сервісу, а проводити - після функціональних тестів, коли виправлені всі недоліки функціоналу.
Крок 1. Цілі і вимоги
Формулюємо їх до початку робіт. Від цього буде залежати, яким чином ми будемо навантажувати систему і які показники будемо дивитися. Для різних цілей аналіз буде різним.
Цілі, наприклад, можуть бути такі:
Визначити максимальну продуктивність системи на існуючій конфігурації;
Перевірити надійність системи: аналізуємо можливі витоки пам'яті і вплив сторонніх регулярних завдань на роботу системи. Наприклад, коли створюється резервна копія бази даних;
Виявити потенційно «вузькі» місця системи.
Основні вимоги зазвичай такі:
Час обслуговування: 90% запитів повинні обслуговуватися в межах 10 секунд. Вимагати обслужити вчасно все 100% запитів безглуздо - 10% це резерв для позаштатних ситуацій і статистичних викидів. Для різних запитів вимоги часу обслуговування можуть відрізнятися: для переходу на внутрішню сторінку потрібні частки секунд, а для завантаження річного звіту - кілька хвилин;
Ємність: система повинна обслуговувати 100 одночасних користувачів і залишатися в рамках пункту 1.
У загальних випадках, для початку тестування такого формулювання вимог досить. Якщо ж система використовує нестандартні протоколи або функціонал: відео, стрімінг, вимоги будуть формулюватися індивідуально.
Крок 2. Сценарії користувача
Наступним кроком відтворюємо роботу реальних користувачів з системою. Для цього потрібні призначені для користувача сценарії, на основі яких будемо навантажувати систему.
Сценарій замовлення товару в інтернет-магазині
При підготовці сценаріїв навантажувального тестування не потрібно покривати всю існуючу функціональність, тому виділяємо найважливіші і часто використовувані дії користувачів: пошук, вибір і покупка, оплата, оформлення замовлення. Чи не беремо до уваги, наприклад, зміну пароля, зміна аватарки або паспортних даних - це той функціонал, який не позначиться на загальній оцінці працездатності системи. Це заощадить час на розробці скриптів.
Крок 3. Інструменти тестування
Основний інструмент навантажувального тестування, який ми використовуємо, - Jmeter . Це не єдиний інструмент, але найбільш популярний. Він підходить для більшості проектів завдяки гнучкості, платформ і підтримки великого числа протоколів. До того ж, Jmeter - безкоштовний інструмент, який підтримується великою спільнотою розробників: вони самі покращують готове рішення, яким можна скористатися безкоштовно.
Для Jmeter розробляємо скрипти: набір команд, що відправляються на сервер при активності користувача. Кожен скрипт імітує окреме дію користувача: вхід, введення логіна / пароля, пошук, додавання товарів в корзину і т.д. Разом вони утворюють користувальницький сценарій з кроку 2. Щоб перевірити, скільки користувачів витримає система, використовуємо кілька віртуальних користувачів в групі (їх кількість залежить від цілей і вимог з кроку 1).
Крок 4. Тестові дані і скрипти
Візьмемо навантаження інтернет-магазину. Щоб її перевірити, нам потрібні достатня кількість унікальних користувачів, документів або товарів.
Припустимо, передбачувана кількість клієнтів - 1000 осіб. В цьому випадку перевіряємо, як буде працювати система, якщо все 1000 осіб будуть замовляти товари одночасно. Значить, створюємо 1000 користувачів. Якщо в майбутньому число користувачів збільшиться, створюємо більше користувачів заздалегідь, щоб дізнатися межа відвідувачів, який система здатна витримати.
- Перед безпосереднім тестуванням перевіряємо, щоб:
- всі скрипти були налагоджені;
- тестові дані підготовлені;
- узгоджена навантаження, яка буде подаватися на систему і на серверах;
- встановлені агенти, які будуть стежити за метриками: витратою пам'яті, процесорного часу, файлу підкачки і мережевою активністю.
Крок 5. Безпосередньо навантаження
Будуємо профіль навантаження виходячи з мети. Наприклад, для визначення ємності системи конфігуруємо тест так, щоб число працюючих користувачів росло. Моніторимо сервера, час відповіді і частку помилок, помічаємо коли відбувається перша точка перегину - насичення тесту. Це точка початку деградації: начебто навантаження ще тримаємося в межах вимог, але межа ресурсів машини вже близько.
Перше насичення тесту відбулося на позначці "точка деградації"
Наступна точка порушення вимог - ми йдемо за межі нормального обслуговування. Система працює, але це наш межа нормального обслуговування.
Система на межі нормального обслуговування
Ми йдемо далі і намагаємося працювати далі, як вийде. Наступний крок - точка відмови: пам'ять або процесорний час закінчується, і сервіс «замовкає». Тут зупиняємо тест і фіксуємо граничну ємність системи.
Точка відмови: пам'ять або процесорний час закінчується
Крок 6. Аналіз результатів
Аналізуємо дані, отримані в ході тестування: метрики, логи додатки, дані про утилізацію ресурсів кожного з серверів системи, логи бази даних і виявляємо проблемні і «вузькі» місця. Проблеми можуть виявитися різноманітними: від невірної настройки якогось сервера, що входить в систему, до взаємних блокувань процесів в базі даних або помилки в коді програми. Часто подібні проблеми неможливо виявити на етапі функціонального тестування, коли системою користується 2-3 людини. Без навантажувального тестування проблема виявиться на етапі експлуатації, коли додатком почнуть користуватися сотні і тисячі відвідувачів.
Що стосується «вузьких» місць системи або архітектури, то швидкість системи - це швидкість самого повільного її компонента. Припустимо, що система складається з декількох мікросервісов. У кожного є свій час відгуку і стійкість до навантаження. Додамо сюди тип бази даних, сервера і конфігурацію обладнання. Користувачам додатка потрібен швидкий відгук системи і її доступність. У процесі аналізу навантажувальних тестів виявляємо вузькі місця в архітектурі і незалежно масштабується і налаштовуємо мікросервіси, щоб домогтися швидкого відгуку системи цілком. Виявлення одного з таких вузьких місць, або «пляшкових шийок», видно на графіку залежності утилізації процесорних потужностей одного з серверів системи від кількості користувачів, що одночасно працюють з системою. Коли кількість відвідувачів перевищила 200 користувачів, завантаження процесора даного сервера досягла 100%, і весь сервіс переставав відповідати. До слова, навантаження було менше, ніж передбачувана кількість реальних користувачів.
Графік залежності утилізації процесорних потужностей від кількості користувачів
Як тільки на сервері модернізували процесор, кількість одночасних користувачів зросла в 2,5 рази. Це перевищувало плановану навантаження на сервіс.
Після тестування навантаження складається звіт про результати тестування. Він включає список помилок, пропозиції щодо оптимізації роботи системи і загальні рекомендації.
підсумки
Багато нехтують перевіркою навантаження, сподіваючись, що до проблем не дійде. Як то кажуть, довіряй, але перевіряй. Перевірка навантаження перед запуском сервісу вбереже продукт від повільної і некоректної роботи, визначить межу його працездатності саме на обраному обладнанні. Практика показує, що простих коригувань конфігурації досить, щоб прискорити проект в 5-10 разів і зробити його стійким до стресових навантажень.
Чи буде воно працювати, якщо кількість користувачів збільшиться?Яка кількість користувачів здатні витримати сервера?
Що станеться, якщо навантаження стане більше, ніж здатні витримати сервера?
Чи зможуть сервера відновити свою роботу і за який час, якщо кількість відвідувачів призведе до збою системи?
Чи буде сервіс працювати також стабільно через тиждень, місяць, рік?