Як обговорювати результати тестування навантаження в англійській мові

Представлення результатів тестування навантаження так само важливо, як і запуск самого тесту - погано пояснений звіт може приховати реальний ризик або викликати непотрібну паніку. Інженерам потрібно підсумувати пропускну здатність, затримку і точки відмови таким чином, щоб як технічні колеги, так і менш технічні зацікавлені сторони могли діяти. У цьому повідомленні наведено словниковий запас і фрази, які вам слід використовувати для чіткого представлення результатів тестів навантаження у оновленнях стану, переглядах готовності або післяопераційних висновках.

Ключовий словник

** Прохідність ** — кількість запитів або транзакцій, які система може успішно обробити за одиницю часу під навантаженням. “Ми підтримували пропускну здатність 2400 запитів на секунду до того, як затримка почала знижуватися.”

** Перцентиль затримки (p95/p99) ** — статистична мірка, що показує час відповіді, нижче якого даний відсоток запитів падає, використовується для опису продуктивності хвоста, а не середніх значень.

• “Средняя задержка выглядела хорошо на 80 мс, но p99 поднялась до 1,2 секунды при максимальной нагрузке.” *

** Точка переривання ** - рівень навантаження, при якому продуктивність системи різко знижується або не спрацьовує, визначаючи практичну межу поточної потужності. “Ми знайшли точку переривання на рівні близько 5000 одночасних користувачів, де кількість помилок стрибнула з 0,1% до 12%.”

** Період підвищення швидкості ** — фаза тестування навантаження, під час якої імітований трафік поступово зростає до цільового рівня, а не починається відразу з повного навантаження. “Ми використовували 10-хвилинний період підйому, щоб уникнути виклику хибних тривог від холодних кешів.”

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

• “Вузьким місцем виявилося з’ єднання з базою даних, а не самі сервери програм.” *

** Пробний тест ** — тест завантаження, який виконується протягом тривалого періоду часу під тривалим, реалістичним навантаженням, щоб виявити проблеми, такі як витік пам’ яті, які з’ являються лише з плином часу. “Тест занурення тривав шість годин і виявив витік повільної пам’яті у шарі кешування.”

** Бюджет помилок ** — допустима межа невдалих або погіршених запитів під час тесту навантаження, використовується як поріг успішності/ невдачі проти цілі надійності системи. “Ми не перевищили допустимої похибки на 0,5% протягом усього тесту, тому ми називаємо це успішним.”

Звичайні фрази

• «Система підтримувала стабільність до 3000 одночасних користувачів, з затримкою p95 менше 200 мс.»
• «Ми визначили базу даних як головне вузьке місце під час пікової навантаження»
• «Рівень помилок залишався в межах прийнятних порогів, поки ми не досягли приблизно 80% цільової здатності»
• «Ми рекомендуємо масштабувати базу з’єднань перед наступним тестом навантаження»
• Ці результати вказують на те, що ми готові до прогнозованого запуску з певною маржою»
• Це блокуючий висновок — ми не повинні переходити на живий, поки вузької місцини не буде вирішено. “

Приклади висловлювань

Оголошую команді про результати тесту навантаження:

• “Завершено перевірку завантаження служби отримання. Ми досягли мети 1500 запитів за секунду з затримкою p95 на 180 мс і нульовим рівнем помилок. Ми впевнені, що це відповідає вимогам потужності для запуску в п’ятницю. ”*

Передача виклику: “Під час сьогоднішнього тесту завантаження, ми побачили, що кількість помилок піднялася до 9%, коли одночасних користувачів перевищило 4000, значно нижче нашого прогнозованого піку 6000. Головною причиною, здається, є вичерпання резерву з’ єднань у службі платежу. Я б хотів розглядати це як блокування для запуску, поки ми не вирішимо це і перевіримо знову.”

Підтримка після виправлення:

• “Ми перезапустили тест навантаження після збільшення розміру пулу з’ єднань і додали автоматичний виключник. Частота помилок зараз залишається нижче 0,2% до 7000 одночасних користувачів, комфортно вище нашого прогнозованого піку. Приєднання повного звіту для посилання».*

Професійні поради

• Звітувати як про середню, так і про затримку p95/ p99 — середні значення можуть приховати серйозні проблеми з затримкою хвоста, які впливають на реальних користувачів.
• Зазначте ** точку зупинки ** явно у відношенні до очікуваного виробничого трафіку, щоб зацікавлені сторони могли судити про межу безпеки на перший погляд.
• Використовуйте “блокатор” навмисно, коли виявлення повинно зупинити випуск — резервування слова для справжніх блокаторів зберігає його сенс.
• При презентації нетехнічним зацікавленим сторонам, перекладайте технічні показники на бізнес-вплив, наприклад, «система може обробляти приблизно 3x наш очікуваний трафік Чорної п’ятниці»

Практичні вправи

1. Напишіть резюме у два речення про тест навантаження, який пройшов успішно, включаючи одну конкретну метрику.
2. Створити чернетку повідомлення з описом перевірки навантаження, яка виявила вузлове місце, і рекомендувати його як блокувальник для випуску.
3. Поясніть у двох реченнях, чому затримка p95 корисніша за середню затримку при обговоренні результатів тестів навантаження.

Наприклад, англійська мова має особливі слова для не-індіанців

Ефективне представлення результатів тестування навантаження не просто про числа; це про передачу * розуміння * цих чисел, їх наслідків і необхідних дій. Для розробників, чия перша мова не є англійською, це може бути особливо складним завдяки тонким відмінностям у тому, як ми визначаємо причинність, відповідальність і невідкладність. Давайте розглянемо деякі типові сценарії і як підійти до них з точністю.

Часта проблема виникає під час перегляду коду при обговоренні піку затримки, спостереженого під час тестування навантаження. Замість того, щоб просто сказати «Тест навантаження зазнав невдачі», що залишає рецензента вгадувати, спробуйте сформулювати його більш конкретно: «Я помітив значне збільшення середнього часу реакції — приблизно 300 мс — під час тесту тривалого навантаження на 100 одночасних користувачів. Це відбулося в основному на кінцевій точці /api/v1/users, як це вказано даними моніторингу. Це вказує на потенційну суперечку навколо запитів бази даних, пов’язаних з пошуком користувачів. “Зауважте використання “значного збільшення”, “середнього часу відповіді”, і визначення * де * проблема була - важливі деталі, які негайно привертають увагу. Уникайте нечітких термінів, таких як « це повільно » або « завантаження погане ». Використання точних вимірювань і посилання на певні компоненти (« /api/v1/users кінцева точка ») показує глибше розуміння і надає змогу проводити цілеспрямовані дослідження. Крім того, додавання короткої пропозиції — «Може бути, дослідження оптимізації запиту може бути корисним» — показує, що ви не тільки вказуєте на проблему, але і пропонуєте рішення, яке високо цінується в професійному спілкуванні.

Інша ситуація включає в себе опис результатів менеджеру продукту або бізнес-зацікавленій стороні. Поширена помилка полягає в тому, щоб зосередитися виключно на технічному жаргоні. Замість того, щоб сказати «Система досягла свого обмеження TPS», що може нічого не означати для когось без глибокого розуміння інфраструктури, скажіть: «Ми спостерігали, як система досягає своєї максимальної потужності обробки транзакцій — 50 транзакцій на секунду — під тривалим навантаженням. Це вказує на те, що наша поточна архітектура може потребувати масштабування або оптимізації для обробки очікуваного майбутнього зростання. » Підсвічування * впливу * (« максимальної потужності обробки транзакцій ») і поєднання його з більш широким питанням (майбутнє зростання) робить інформацію більш доступною. Також корисно кількісно оцінити потенційний вплив, навіть якщо це лише оцінка: « Це може призвести до затримок для користувачів під час періодів піку ». Нарешті, завжди визнайте обмеження — « Ці результати засновані на нашому поточному тестовому середовищі і можуть не повністю відображати виробничі умови ». Прозорість створює довіру.

Нарешті, враховуйте повідомлення Slack при повідомленні про результати. Швидкого, реактивного повідомлення на зразок « Перевірка завантаження зазнала невдачі » недостатньо. Замість цього, створіть коротке оновлення: «Тест навантаження для нової функції показав збільшення затримки при 50 одночасних користувачах — пік на 180 мс на маршруті /checkout. Мы изучаем потенциальные узкие места в базе данных. Буде надано оновлення до кінця дня». У цей список буде включено ключову метрику (затримку), конкретну кінцеву точку, на яку впливає оновлення, а також чітке вказівку щодо ваших наступних кроків. Використання фраз на кшталт «потенційні вузли бази даних» відповідно обрамляє проблему, не перевантажуючи отримувача технічними деталями. Пам’ятайте, що ясність і активне спілкування є найважливішими при обговоренні проблем продуктивності - особливо при роботі в командах з різними рівнями технічної експертизи.