Стендап Сьогодні 📢 Канал в Telegram @stendap_sogodni
🤖🚫 Контент вільний від AI. Цей пост на 100% написаний людиною, як і все на моєму блозі. Насолоджуйтесь!03.04.2023
Стрес-тест як дослідження системи
На першу чергу, метою стрес-тесту є обчислення деяких метрик. Насправді на мою думку, обчислення метрик — це тільки початок роботи. Мені більше цікаві пояснення цих метрик, та уявлення про роботу системи, яке можна з них отримати. Для мене головне питання стрес-тесту — у що він упреться?
Що я маю на увазі. Щоб дізнатись, на що здатна система, треба завантажити її на 100%. Але, в розподілених системах (якою є навіть додаток з його базою даних) навантаження ніколи не накладається рівномірно — обовʼязково є вузьке місце. Після отримання результатів стрес-тесту необхідно знайти це місце, а далі найцікавіше — прибрати вузьке місце, та спробувати тест знову. Повторювати до тих пір, поки не буде чітко знайдено місце, яке неможливо “розширити” (та тому причина) - воно і є справжнім обмеженням всієї системи.
Наприклад, протестували API. Перевіряємо — де 100%? Якщо ніде немає — недовантажили мережу. Треба більше запитів. Зробили більше запитів — бачимо, база натужилася. Знайшли N+1 запит — виправили. Нарешті, тепер бачимо 100% CPU додатка. Якщо припустити, що в додатку немає що оптимізувати, то тепер ми маємо справжню картину. Але можна й взяти профайлер, та продовжувати вже на рівні коду — всередині додатка теж буде вузьке місце.
Без цих дій, на мою думку, стрес-тест власної системи — марна витрата часу. Це як розганяти машину на першій передачі — якесь число ми отримаємо, але хіба воно буде корисне? Тільки як показник “як все було погано”.