Англійська для Locust Load Testing

Locust — інструмент тестування навантаження, де тестові сценарії написані як звичайний код Python, а не як власне DSL, що робить його гнучким, але означає, що команди потребують спільного словника — «клас користувача», «задача», «швидкість спаунінгу», «RPS» — для обговорення дизайну тестів без двозначності. Неясне повідомлення « перевірка завантаження зазнала невдачі » приховує, чи система зазнала аварії, чи зазнав аварії скрипт перевірки, чи результати просто було неправильно прочитано. Цей підручник містить англійську мову, яку використовують під час обговорення Locust з командою.

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

** User class ** — клас Python, що визначає поведінку симульованого користувача (які кінцеві точки він зачіпає, у якому шаблоні, з яким часом очікування між діями), основний блок тесту Locust.

• “Додати окремий клас користувача для потоку вилучення — змішування його з класом користувача навігації ускладнює керування співвідношенням між цими двома поведінками.” *

** Задача (і вага задачі) ** — метод у межах класу користувача, який представляє одну дію, яку може виконати імітований користувач, з можливістю врахування ваги, щоб деякі дії виконувалися частіше, ніж інші, що відповідає реальним шаблонам потоку даних. “Надати завданню сторінки продукту більшу вагу, ніж завданню оплати — у реальному трафіку, набагато більше користувачів переглядає сторінку, ніж насправді завершує покупку.”

** Частота появи (збільшення) ** — швидкість, з якою Locust додає нових симульованих користувачів під час тестування, відрізняється від загальної кількості користувачів; низька частота появи збільшується поступово, а висока частота досягає цільового навантаження майже відразу. “Сповільнити швидкість відновлення — перехід до п’яти тисяч користувачів за десять секунд тестує сценарій піку трафіку, а не стабільний стан навантаження, який ми насправді хотіли виміряти сьогодні.”

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

** Розподілений режим (головний/ робочий) ** — запуск Locust на декількох робочих процесах або машинах, координованих головним процесом, необхідний, коли одна машина не може самостійно генерувати достатню кількість навантаження, щоб напружити систему- ціль. “Одна машина не могла перетнути три тисячі симульованих користувачів без того, щоб сама Locust не стала вузлом - ми переключилися на розподілений режим з чотирма працівниками, щоб перетнути цю межу.”

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

• Чи є це окремим класом користувача, чи воно повинно бути зваженим завданням в рамках існуючого?»
• «Яку швидкість спаунування ми використовуємо — чи тестуємо ми постійне навантаження або раптову стрімку швидкість?»
• “РПС опустились до уровня, когда мы достигли целевого количества пользователей? Це варто розслідувати самостійно»
• «Чи потрібний нам розподілений режим, чи достатньо однієї машини для генерації необхідного навантаження?»
• Чи це несправність системи під час тестування, чи сам Locust виходить з ресурсів?»

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

Перегляд запиту на звантаження:

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

Пояснення рішення про проектування: “Ми навмисно встановили повільний темп оновлення для цього тесту, оскільки ми моделюємо поступове щоденне зростання трафіку, а не пік розпродажів — це окремий тестовий сценарій.”

Опис події: “Тест навантаження виглядав так, ніби він зазнав невдачі, але RPS фактично зафіксувався набагато раніше, ніж кількість цільових користувачів — в’ язким місцем був пул з’ єднань бази даних, а не Locust, який вимагав більше потужності.”

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

• Використовуйте “user class” і “task” точно, коли обговорюєте дизайн тесту — це два будівельні блоки, і нечіткі описи, такі як “тестовий скрипт”, ускладнюють обґрунтування тестового покриття.
• Розрізняти ** частоту появи ** від ** загальної кількості користувачів ** явно — тест може не дати реальних умов, якщо зростання не відповідає моделі трафіку.
• Перевіряйте і повідомляйте про ** RPS plateauing **, а не лише про кількість досягнутих користувачів — система може досягти свого реального максимуму ще до того, як буде досягнуто імітованої цілі користувача.
• Згадайте про розподілений режим, коли здатність генерувати навантаження, а не цільова система, є справжнім вузьким місцем — це інша проблема, ніж те, що система під тестуванням повільна.

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

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

Навігація та зв’язок

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

Поширеним сценарієм є отримання коментарів перегляду коду на запит збирання, де продуктивність не ідеальна. Рецензент може залишити коментар на зразок: « Цю петлю можна було б оптимізувати — розгляньте можливість використання ефективнішого алгоритму або зменшення кількості ітерацій ». Простий переклад цього слова буквально може призвести до плутанини. Ключ тут - розуміння прихованого значення і активна реакція. Замість того, щоб оборонно сперечатися про буквальний переклад, ви хотіли б визнати свою занепокоєність: «Дякую за позначення цього! Я розгляну потенційні вузли в петлі і досліджу альтернативні алгоритми. Чи могли б ви, можливо, показати мені деякі ресурси щодо спільних стратегій оптимізації у Python?» Зауважте, як ця фраза демонструє бажання вчитися і співпрацювати — важливий елемент професійної англійської мови.

Інша часта ситуація виникає під час обговорення про зростання рою, особливо при повідомленні результатів після тесту Locust. Уявіть повідомлення Slack: « Розгортання рою було значно повільнішим, ніж очікувалося; ми побачили пік у 80 користувачів, перш ніж програма почала повільно відповідати ». Безпосередній переклад може не дати вам зрозуміти, що це важливо. Натомість, більш ефективним підходом було б: «Гаразд, це турбує. Повільний ріст впливає на нашу здатність точно імітувати реальні поведінку користувачів. Давайте розглянемо конфігурацію - конкретно, чи ми обмежуємо кількість одночасних користувачів або є якісь обмеження в самому додатку? “Використання фраз на кшталт “це турбує” і обрамлення проблеми як вплив на “точне моделювання” підкреслює важливість тестування продуктивності.

Нарешті, при описі результатів тесту для зацікавлених сторін, точність є найважливішою. Замість того, щоб сказати щось нечітке, наприклад, «система працювала добре», ви хочете сформулювати конкретні показники: «Під час тестування навантаження ми спостерігали середній час реакції 200 мс з максимумом 500 мс під тривалим навантаженням 100 одночасних користувачів — значно краще, ніж наш початковий базисний рівень». Такий рівень деталізації демонструє професіоналізм і дозволяє зацікавленим сторонам зрозуміти вплив вашої роботи.

locust -f locustfile.py --headless --users 100 --host http://localhost:8080 --time 60

Ця проста команда locust ілюструє звичайний робочий процес - запуск тесту з командного рядка для оцінки продуктивності, і розуміння виводу, який часто включає такі показники, як середній час відповіді і запити на секунду. Сфокусування уваги на цих ключових фразах і підходах значно поліпшить вашу здатність ефективно робити свій внесок у англомовне середовище розробки.