Три этапа поиска максимальной производительности

Частая задача в тестировании производительности - поиск максимальной производительности при заданном профиле нагрузки или нагрузочное тестирование или Load Testing.
Для распределенных систем удобно разделить процесс на три этапа:
- прогрев;
- поиск максимальной производительности;
- подтверждение тестом стабильности.
Все просто, но есть нюансы. Доклад обзорный, с примерами реализации в Apache.JMeter и Gatling

Transcript

1. Три этапа поиска максимальной производительности Смирнов Вячеслав
2. Ускоряю vtbbo.ru ДБО для юр. лиц Развиваю @qa_load сообщество инженеров Выступаю, пишу статьи Читаю почту owasp@ya.ru
3. Задача: провести тестирование производительности А что это? А какая цель тестирования? А какие инструменты использовать?
4. Gatling
5. Gatling
6. Задача по умолчанию: поиск максимальной производительности Сформировать требования по 1. Доле ошибок (0%, нет резкого роста % ошибок) 2. Времени отклика (95%% длительности не превышает 60 сек) 3. Утилизации ресурсов (100 ядер CPU, 100 Мбит/с на сетевой канал) Смоделировать нагрузку 1. Прогревающую 2. Возрастающую 3. Стабильную Найти интенсивность, при которой система 1. Перестает удовлетворять требованиям производительности 2. Удовлетворяет требованиям производительности
7. Методика и Профиль нагрузки 7 Методика Профиль нагрузки, требования Подготовка данных и стенда Изучение работы с системой Разработка тестов и заглушек Запуск тестов Анализ метрик и логов Отчёт и инструкции Профиль нагрузки, требования
8. Разработка и запуск тестов 8 Методика Профиль нагрузки, требования Подготовка данных и стенда Изучение работы с системой Разработка тестов и заглушек Запуск тестов Анализ метрик и логов Отчёт и инструкции Профиль нагрузки, требования
9. Сформировать требования 1. По доле ошибок • 0% ошибок • нет резкого роста % ошибок 2. По времени отклика • длительность у 95% сценариев в течение минуты не превышает 60 сек • длительность каждого сценария не превышает 90 сек 3. По утилизации ресурсов • 100 ядер CPU • 100 Мбит/с на сетевой канал • Длина очереди не более 1000 элементов
10. Смоделировать нагрузку 1. Прогревающую (первый шаг) • Реализовать просто • Не нужны таймеры 2. Возрастающую • Реализовать сложно • Нужны таймеры, ступени, потоки 3. Стабильную • Реализовать нужно • Реализовать несложно Изображение Jonas Jovaisis с сайта Pixabay
11. Смоделировать нагрузку 1. Прогревающую • Реализовать просто • Не нужны таймеры 2. Возрастающую (процесс) • Реализовать сложно • Нужны таймеры, ступени, потоки 3. Стабильную • Реализовать нужно • Реализовать несложно
12. Смоделировать нагрузку 1. Прогревающую • Реализовать просто • Не нужны таймеры 2. Возрастающую • Реализовать сложно • Нужны таймеры, ступени, потоки 3. Стабильную (цель) • Реализовать нужно • Реализовать несложно
13. Три этапа поиска максимальной производительности (интенсивности) 1. Прогреть систему • Прогревающей нагрузкой • Предварительный тест 2. Найти максимальную производительность • При возрастающей интенсивности • Контролируя ошибки 3. Подтвердить найденный максимум тестом стабильности • Стабильная нагрузка на 80% от максимума • Долгая, при которой не будет ошибок
14. Рекомендуемые инструменты Apache.JMeter и Gatling: 1. Большое количество протоколов и плагинов. 2. Гибкая настройка профиля нагрузки. 3. Высокая производительность. 4. Хорошие отчеты. 5. Open Source.
15. 1. Прогревающая нагрузка А какая цель прогрева? А как это реализовать в Apache.JMeter и Gatling? Как анализировать результаты прогревающего теста?
16. Прогревающая нагрузка 1. Прогреть систему малой нагрузкой • избавить последующий тест от зависания 2. Выполнить за 15 минут • прогрев не должен быть долгим 3. Выполнить 5 успешных сценариев • сценарий должен падать при нарушении SLA Самый простой тест в 1-2 потока без пауз
17. Прогрев работает в 1 поток без пауз (самая простая реализация)
18. Прогрев работает в 1-2 потока без пауз (самая простая реализация)
19. Длительность выполнения при этом снижается от итерации к итерации
20. 2. Возрастающая нагрузка (есть разные реализации) Реализация без пауз и таймеров, только увеличение количества потоков Реализация контролем интенсивности (TPS или RPS) Реализация с контролем интенсивности и ступенчатым увеличением нагрузки
21. 2.1. Возрастающая нагрузка (без пауз и таймеров) Какие плюсы и минусы такой реализации нагрузки? А как это реализовать в Apache.JMeter и Gatling? Как анализировать результаты возрастающей нагрузки?
22. Возрастающая нагрузка без пауз и таймеров 1. Оценить длительность выполнения сценария (t мсек) • запустив предварительный тест, например, тест прогрева 2. Рассчитать интенсивность работы одного потока (X = 1000/t) • значение обратное длительности 3. Рассчитать интенсивность теста при N потоках (TPS = X•N) • сценарий должен падать при нарушении SLA Сценарии выполняются без пауз. Подходит для высокой нагрузки (100+ TPS) и простых сценариев: 1-10 несвязанных запросов. При сложных долгих сценариях способ становится неточным.
23. Сценарий состоит из нескольких простых, не связанных между собой запросов
24. Если их выполнить несколько раз, то можно оценить вероятную длительность (50%%)
25. И рассчитать интенсивность при кратном увеличении количества потоков
26. Запросы не связаны между собой и при ошибках тест может продолжаться
27. Продолжать тест при ошибках – поведение по умолчанию
28. Получаем растущую интенсивность (Throughput)
29. 2.2. Возрастающая нагрузка (с таймерами и контролем интенсивности) Каковы плюсы и варианты реализации контроля интенсивности? А как это реализовать в Apache.JMeter и Gatling? Как анализировать результаты и выбрать максимальную интенсивность?
30. Запросы могут быть зависимы друг от друга
31. Если один запрос упал, то продолжать цепочку уже нельзя, она стартует заново
32. Для контроля интенсивности вводят понятие «шага нагрузки» - длительность цепочки операций или сценария Шаг нагрузки
33. Шаг нагрузки выбирается с запасом
34. Даже если запросы падают – шаг нагрузки соблюдается
35. Если запрос зависает, то шаг растягивается и интенсивность снижается
36. Шаг нагрузки реализуется таймерами (пример: шаг 2 сек)
37. При ошибке начинаем снова
38. Возрастающая линейно нагрузка Работа с потоками: • Thread Group Таймер для контроля интенсивности: • Constant Throughput Timer (внутри Flow Control Action)
39. Возрастающая линейно нагрузка rampUsersPerSec setUp( userOpenMainPage .inject( rampUsersPerSec(0) to (maxTPS) during (duration_sec seconds) ) .protocols(Protocol.httpConf) )
40. Нагрузка в данном случае растет линейно
41. 2.3. Возрастающая нагрузка (с таймерами и ступенями) Какие плюсы и варианты реализации возрастающей ступенями нагрузки? Как анализировать результаты и выбрать максимальную ступень? А как это реализовать в Apache.JMeter и Gatling?
42. Возрастающая нагрузка (ступенями) с контролем TPS 1. Подать контролируемую нагрузку • и найти интенсивность при которой система удовлетворяет SLA 2. Длительность ступени постоянная – 15 минут • ступеней в тесте 5-10 штук, начиная со средней нагрузки 3. Нагрузка подается выше ожидаемого максимума • сценарий должен падать при нарушении SLA Ступень – малый тест стабильности, удобный в анализе
43. Возрастающая нагрузка (ступенями) с контролем TPS
44. Следим за длительностью выполнения сценариев
45. Ищем точку (ступень) деградации производительности, «разладки»
46. И точку (ступень) недоступности, при которой время отклика больше не растет
47. Обязательно следим за всеми ошибками
48. И ищем точку (ступень) появления или начала роста ошибок
49. Анализ утилизации ресурсов позволяет найти узкое место системы
50. Мониторинг утилизации ресурсов должен быть детальным
51. Цель в поиске точек (ступеней) деградации, ошибок, недоступности
52. И в поиске точки (ступени), когда система удовлетворяет SLA
53. 80% от точки деградации/«разладки» или предыдущая ступень
54. Возрастающая ступенями нагрузка Работа с потоками: • Ultimate Thread Group • Concurrency Thread Group Таймер для контроля интенсивности: • Constant Throughput Timer • внутри Flow Control Action • this thread only • Интенсивность для одного потока
55. Возрастающая ступенями нагрузка incrementUsersPerSec setUp( userOpenMainPage .inject( incrementUsersPerSec(incrementUsersPerSec_int) .times(numberOfSteps) .eachLevelLasting(levelDuration) .separatedByRampsLasting(rampDuration) .startingFrom(initialUsersPerSec) ) .protocols(Protocol.httpConf) )
56. Возрастающая ступенями нагрузка pase + incrementConcurrentUsers val userOpenMainPage : ScenarioBuilder = scenario(cfg.title()) .forever( pace(pase_ms millisecond) .exec( SimpleScenario.simpleScenario() ) ) setUp( userOpenMainPage .inject( incrementConcurrentUsers(virtual_users_count) .times(numberOfSteps) .eachLevelLasting(levelDuration) .separatedByRampsLasting(rampDuration) .startingFrom(initialConcurrentUsers) ) .protocols(Protocol.httpConf) )
57. 3. Стабильная нагрузка (с разгоном) Какие плюсы и варианты реализации возрастающей ступенями нагрузки? А как это реализовать в Apache.JMeter и Gatling? Как анализировать результаты и выбрать максимальную ступень?
58. Для стабильной нагрузки потоки и интенсивность должны быть стабильны
59. Но если подавать такую «ровную» нагрузку
60. Она будет ровной в TPS (транзакции в сек)
61. Но не будет ровной в RPS (запросы в сек)
62. Для стабильной нагрузки важен разгон
63. Или паузы между запросами
64. Или разгон с паузами вместе
65. Тогда нагрузка будет ровной
66. Стабильная нагрузка с разгоном в Apache.JMeter
67. Стабильная нагрузка в TPS с разгоном в Apache.JMeter Работа с потоками: • Thread Group, Ultimate Thread Group • Concurrency Thread Group Таймер для контроля интенсивности: • Constant Throughput Timer • внутри Flow Control Action • all active threads in current thread group (shared) • интенсивность для всех потоков внутри катушки
68. Стабильная нагрузка в RPS с разгоном в Apache.JMeter Работа с потоками: • Thread Group, Ultimate Thread Group • Concurrency Thread Group Таймер для контроля интенсивности: • Constant Throughput Timer • all active threads in current thread group (shared) • интенсивность для всех потоков внутри катушки
69. Стабильная нагрузка в TPS: constantUsersPerSec setUp( userOpenMainPage .inject( constantUsersPerSec(maxTPS) during (duration_sec seconds) ) .protocols(Protocol.httpConf) )
70. Стабильная нагрузка в TPS: pase + constantConcurrentUsers val userOpenMainPage : ScenarioBuilder = scenario(Protocol.cfg.title()) .forever( pace(pase_ms millisecond) .exec( SimpleScenario.simpleScenario() ) ) setUp( userOpenMainPage .inject( constantConcurrentUsers(virtual_users_count) during (duration_sec seconds) ) .protocols(Protocol.httpConf) )
71. Стабильная нагрузка в RPS: throttle .throttle( jumpToRps(maxRPS), holdFor(duration_sec seconds) )
72. Выводы JMeter и Gatling удобны Ошибки – основная метрика в нагрузке Прогрев защищает от ошибок Контроль TPS/RPS для сложных тестов Анализ ступеней очень прост Тест стабильности гарантирует точность
73. Что почитать и посмотреть Статьи, книги Видео Код
74. Возрастающая нагрузка без пауз и таймеров в JMeter Подробно описана в статье «Управление мощностями: в поисках идеального баланса» Давыдов Иван @AntreTick, ЮMoney (Яндекс.Деньги) habr.com, 25 января 2019 https://habr.com/ru/company/yoomoney/blog/437416/
75. Сборник статей по JMeter в виде книги «Master JMeter from Load Testing to DevOps» https://www.ubik-ingenierie.com/blog/book- master-jmeter-from-load-testing-to-devops/ https://www.packtpub.com/product/master- apache-jmeter-from-load-testing-to- devops/9781839217647
76. Документация по Gatling DSL gatling.io/docs/current/cheat-sheet/
77. Курс по Gatling https://gatling.io/academy/
78. Gatling Fundamentals for Stress, Load & Performance Testing (James Willett) udemy.com/course/gatling-fundamentals/
79. Примеры кода github.com/polarnik/jmeter_max_perf_and_stable_test