Load testing with Tsung
2 likes1,628 views
Доклад Александра Чистякова о нагрузочном тестировании веб-приложений с использованием инструмента Tsung обсуждает важность этого процесса, этапы его реализации и общие ошибки. Он подчеркивает необходимость корректного мониторинга и коммуникации между командами разработчиков и инженеров эксплуатации для выявления «горячих точек» приложения. В завершение, Чистяков описывает технические детали настройки Tsung и интерпретации полученных отчетов.
Load testing with Tsung
- 1. Нагрузочное тестирование веб- приложения с использованием Tsung Александр Чистяков, Cezurity
- 2. Докладчик Работал performance engineer'ом Работает operations engineer'ом Консультирует по вопросам оптимизации производительности веб-сайтов Участвовал в организации стендов нагрузочного тестирования
- 3. Аудитория Инженеры по тестированию Начальники отделов тестирования CIO веб-компаний Веб-разработчики
- 4. Цели доклада Поделиться личным опытом Рассказать об организации процесса нагрузочного тестирования Рассказать от средстве нагрузочного тестирования Tsung Упомянуть о некоторых общих ошибках
- 6. Цели нагрузочного тестирования Этапы создания веб-проекта: Бизнес-идея Техническое задание Разработка согласно ТЗ Тестирование корректности Запуск в продакшн Функционирование в продакшн режиме
- 7. Цели нагрузочного тестирования Первые четыре этапа — в нагрузочном тестировании нет необходимости А на последних двух? Обычно до запуска о нагрузочном тестировании никто не думает И после тоже, пока не начнутся проблемы уже после запуска Эти проблемы напрямую влияют на бизнес
- 8. Что же это за проблемы? В общем виде - “сайт не справляется с нагрузкой”: Сайт не справляется с нагрузкой сразу после запуска Сайт не справляется с нагрузкой из-за увеличения числа пользователей со временем Число пользователей не растет, но сайт все равно перестает справляться
- 9. Как бизнес ставит требования? “Мы должны выдерживать X пользователей на сайте” “Сейчас у нас есть X пользователей на сайте, можем ли мы выдержать Y?” “Вчера у нас было X пользователей на сайте и все работало, почему их сегодня тоже X, а сайт лежит?”
- 10. Формализация Что такое “X пользователей на сайте”? Пользователь был на сайте 2 минуты 47 секунд и просмотрел за это время 3 страницы Пользователь был на сайте 8 часов, провел за это время 15 боев, его браузер сделал 30000 запросов к серверу Необходимо знать, как вел себя пользователь — понятие пользовательской сессии или сценария
- 11. Цели нагрузочного тестирования Имея типичный пользовательский сценарий, определить максимально допустимое количество пользователей, которое может обслужить приложение? Имея прогнозируемую нагрузку, заранее оценить, готово приложение к запуску, или нет? Правильно?
- 12. Неправильно! Результаты будут надежны, только если стенд в точности повторяет продакшн окружение Тестировать приложение под нагрузкой как черный ящик — это слишком дорого Как повысить эффект от нагрузочного тестирования? Правильная постановка целей Правильная организация стенда
- 13. Настоящие цели Произвести измерения временных и количественных характеристик разных составляющих приложения под нагрузкой Определить, как изменяются параметры компонентов приложения в зависимости от характера нагрузки Помочь разработчикам выявить «горячие точки» в приложении Просто взять и запустить генератор нагрузки недостаточно!
- 14. Нужен мониторинг параметров Что же это за параметры? Универсальный параметр — время (время обработки запроса, время, проведенное приложением при обращении к БД, время отрисовки страницы в браузере, etc) Второй универсальный параметр — скорость (на самом деле, это просто величина, обратная времени) Частные параметры
- 15. Частные параметры Большое разнообразие, примеры: Количество занятой и свободной RAM Число операций записи на диск в секунду Длина очереди сервера сообщений Количество занятых процессов демона X Количество full scans в БД Их точный набор необходимо определить вместе с архитектором приложения
- 16. Взаимодействие с командой Разработчики часто не знают ответ на вопрос «почему сайт перестал справляться с нагрузкой» И не хотят об этом думать, так как заняты бизнес-задачами Operations engineer'ы часто знают ответ на этот вопрос Но не в терминах структуры приложения И их усилий часто недостаточно
- 17. Взаимодействие с командой Возможность поставить эксперимент заранее и определить, какая именно подсистема приложения ведет себя хуже всего, существенно упрощает жизнь всем Без вмешательства разработчиков получение данных о работе приложения невозможно К счастью, от них не требуется ничего сложного
- 18. Универсальный параметр - время Разработчикам нужно расставить в коде приложения вызовы, сообщающие мониторингу о начале и конце обработки: $mon = new MonClient(); $mon->start_timer(«DB_request»); $app->do_database_request(); $mon->stop_timer(«DB_request»); $app->do_something_else();
- 19. Мониторинг Простейший случай — запись данных в файл (усреднение и другую обработку данных придется делать вручную) Для PHP-проектов — PINBA Для любых проектов — StatsD + Graphite Munin, OpenTSDB, MRTG, Zabbix и еще десяток названий Кстати, такие же графики крайне желательны и для продакшн системы
- 20. Как создать нагрузку? Взять любой load testing tool Записать в нем пользовательскую сессию Настроить параметры (число пользователей) Запустить тест Правильно?
- 21. Неправильно! Создание нагрузки на приложение также создает нагрузку и на само средство создания нагрузки Не любой load testing tool может создать нужную нагрузку Нужно взять такой, который сможет! Если можно — бесплатный
- 22. Open source load testing tools Apache JMeter Известен всем Написан на Java, имеет красивый UI Больше 200 одновременных пользователей на Core i7 с 8G RAM не генерирует Tsung Почти не известен Написан на Erlang, хорошо масштабируется Больше 1.5K пользователей (с 1500 rps) мне никогда не требовалось
- 23. Как поставить Tsung? Развернуть Linux-окружение Установить Erlang Склонировать из репозитория https://github.com/processone/tsung Скачать .deb или RPM из http://tsung.erlang-projects.org/dist/
- 24. Как записать сессию? Запустить в терминале tsung-recorder -L 59123 start, где 59123 — порт, может быть любой Сконфигурировать локальный браузер на использование прокси http://tsung_host:59123, где tsung_host — адрес машины, где запущен Tsung Моделировать в браузере сессию Выполнить tsung-recorder stop Сессия в файле ~/.tsung/tsung-recorderDATE-TIME.xml
- 25. Что делать с сессией? Весь трафик шел через session recorder, в сессию записались «лишние» домены, такие как metric.yandex.ru и т.п. Сессию необходимо отфильтровать от этих доменов, скрипт фильтрации здесь: https://gist.github.com/alexclear/5232377 tsung-filter.pl session.xml domain.com оставит только domain.com Результат в файле session.filtered.xml Теперь ее надо добавить в конфиг
- 26. Конфигурационный файл tsung Находится по адресу ~/.tsung/tsung.xml DTD: https://github.com/processone/tsung/blob/ma ster/tsung-1.0.dtd Содержит один или несколько элементов session Записанную и отфильтрованную сессию нужно вставить в этот файл Можно использовать несколько сессий, задав им вероятность (сумма вероятностей всех сессий должна быть 100)
- 27. Как задать нагрузку? Нагрузка описывается тегами arrivalphase и users Фаз может быть несколько, они отличаются скоростью поступления новых пользователей и длительностью Скорость поступления новых пользователей задается либо в пользователях за период (атрибут arrivalrate), либо в периоде между пользователями (атрибут interarrival) Можно задать максимум пользователей
- 28. Как задать нагрузку? Пример: <arrivalphase phase="1" duration="20" unit="minute"> <users maxnumber="200" arrivalrate="200" unit="second"/> </arrivalphase> Мы описали 20-минутный интервал, в течение которого будет появляться по 200 пользователей в секунду, но общее число пользователей не будет превышать 200
- 29. Как провести тестирование? Чтобы запустить: tsung start Чтобы остановить: tsung stop В нормальном режиме Tsung должен доработать до конца автоматически, но стенд может отказать раньше Даже при аварийном завершении данные будут собраны Результат в каталоге ~/.tsung/log/DATE- TIME Результат в сыром виде не так интересен, нужно построить графики
- 30. Как построить графики? Перейти в каталог ~/.tsung/log/DATE-TIME Выполнить в нем скрипт /usr/lib/tsung/bin/tsung_stats.pl Отчет будет сгенерирован в формате HTML Отчеты удобно просматривать через веб, если сконфигурировать вебсервер на отдачу статики из каталога ~/.tsung/log /DATE-TIME/graph.html — отчет с графиками /DATE-TIME/report.html — отчет в текстовом виде
- 31. Как интерпретировать отчеты? «Page» в терминологии Tsung это участок сессии без тегов thinktime, может не иметь отношения к реальным страницам на сайте Наибольший интерес представляют графики Simultaneous Users и HTTP Code Response rate Следите за Network Throughput Rate — если пропускная способность канала связи между генератором нагрузки и стендом меньше 100Мбит, она может быть легко превышена
- 32. Выводы Нагрузочное тестирование в отсутствии корректно организованного мониторинга приложения не принесет большой пользы Мониторинг приложения — комплексная задача, которую нужно решать силами всей команды Tsung — высокопроизводительный генератор нагрузки с возможностью построения HTML-отчетов и графиков
- 33. Спасибо за внимание! Вопросы? Александр Чистяков, Cezurity http://alexclear.moikrug.ru http://alexclear.livejournal.com http://slideshare.net/alexclear