Обсудить проект_
Если у вас есть ИТ-проблема, напишите нам в Telegram или оставьте ваши контакты, и мы свяжется с вами для детального обсуждения задачи
Нагрузочное тестирование веб-приложения
Продукт:
Продукт:
Платформа для проведения on-line тестирования. Пиковая нагрузка на платформу приходится на время проведения массовой онлайн-акции.
Задача:
Перед акцией проверить, как платформа работает под ожидаемой нагрузкой, и найти предел — максимальную нагрузку, которую система выдерживает без отказа. Ориентир — около 130 запросов в секунду к серверу.
Тесты шли на стенде заказчика, который примерно в 4 раза меньше продакшена по ресурсам. На время тестов была отключена доставка пароля по SMS и e-mail, а статические файлы не учитывались: их планировали вынести на CDN.
Тесты шли на стенде заказчика, который примерно в 4 раза меньше продакшена по ресурсам. На время тестов была отключена доставка пароля по SMS и e-mail, а статические файлы не учитывались: их планировали вынести на CDN.
Итоги:
Один сервер приложения час стабильно обрабатывал 300–400 хитов в секунду при ориентире около 130; хит — один запрос к серверу. Доля ошибок — 0,04 %, среднее время ответа — не выше 0,5 с. В стресс-тестах на плато было 460–680 хитов в секунду. Предел — около 800 хитов в секунду: процессор сервера приложения загружен полностью. Обнаружили, что при масштабировании добавлением серверов приложений узким местом станет внутренняя сеть 1 Гбит/с, а точкой отказа — сервер БД. Все технические рекомендации, которые можно было применить оперативно, были учтены заказчиком и применены до начала акции.
Период работы:
12–27 апреля 2021 года
Команда:
4 человека: DevOps-инженер, QA Lead, Senior-разработчик, менеджер проекта
Инструменты:
- Apache JMeter
- Terraform
- Ansible
- Yandex Cloud — в нем была развернута ферма генерации нагрузки
Решение:
Работа шла по трём направлениям: модель нагрузки и тесты, ферма генерации нагрузки и аудит конфигурации серверов заказчика.
- Модель нагрузки по поведению участников. Мы изучили сайт, подготовили вопросы заказчику и его ИТ-специалистам — об архитектуре, мониторинге и тестовом стенде — и на созвонах собрали сценарии поведения участников. Опирались и на данные мониторинга прошлого проведения акции. В модели две цепочки: 90 % участников открывают главную страницу, входят в личный кабинет, проходят тест и скачивают диплом (21 запрос), 10 % переходят по страницам сайта (11 запросов). Между переходами пауза около секунды, на ответ на вопрос теста — 45 секунд: это значение определили эмпирически. Виртуальные участники проходили настоящий подготовительный тест платформы, который, по данным разработчиков, повторяет основной. Отдельным шагом перед тестом зарегистрировали 200 000 пользователей, чтобы каждый виртуальный участник входил под своей учётной записью.
- Отладка сценариев. Тест-план собрали в Apache JMeter — инструменте, который имитирует запросы множества пользователей по сценарию. Разобрали, как устроен вход в личный кабинет, отладили сценарии на стенде и искали проблемы, которые блокировали тесты. По ходу нашли ошибку сайта: он отправлял лишний запрос главной страницы. Разработчики её исправили.
- Ферма генерации нагрузки. Нагрузку генерировала ферма виртуальных машин в облаке Yandex Cloud, её разворачивали Terraform и Ansible. JMeter работал в распределённом режиме: машины фермы подают нагрузку по одному тест-плану, запуск теста автоматизирован.
- Калибровка. Перед финальными прогонами провели 8 калибровочных запусков с рабочего места и 3 из облака и по ним подобрали число виртуальных пользователей и паузы в сценариях.
- Финальные прогоны. Финальное тестирование — три запуска: 15 минут нарастания и час стабильной нагрузки, затем два стресс-теста с нагрузкой в 1,5 и 2 раза выше. Во время прогонов следили за стабильностью системы и проверяли результаты. Графики снимали в мониторинге заказчика: недостающие метрики заказчик добавил по нашему списку, для метрик базы данных мы подготовили SQL-запросы. Отслеживали число запросов в секунду, загрузку процессора, Load Average — среднее число процессов, которые выполняются или ждут процессора, — число запросов к базе данных, сетевой трафик серверов приложений и БД и время ответа.
- Что показали графики. Под стабильной нагрузкой средняя загрузка процессора и сетевых интерфейсов сервера не доходила до 100 %. В стресс-тестах загрузка процессора сервера приложения подходила к 100 % — это предел одного сервера на стенде. Внутренний сетевой интерфейс сервера БД во время тестов загружался на 200–500 Мбит/с при пропускной способности внутренней сети 1 Гбит/с. Отсюда главный вывод: если масштабировать систему добавлением серверов приложений, она упрётся во внутреннюю сеть, а точкой отказа станет сервер БД. Ещё одна находка — страницы ошибок не были адаптированы под приложение. Мы рекомендовали сделать статичные страницы, которые просят пользователя повторить запрос или обновить страницу.
- Аудит конфигурации. Ещё до тестов договорились проверить настройки продакшен-серверов, и параллельно с подготовкой тестов мы провели аудит их конфигурации. Рекомендации касались балансировщика на nginx, серверов приложений с PHP-FPM, СУБД MariaDB и сетевого стека ядра. Среди них: согласовать лимит соединений балансировщика с тем, сколько соединений могут принять серверы приложений; включить HTTP/2 и кэш TLS-сессий, который позволяет не устанавливать шифрованное соединение заново при повторном подключении; увеличить очереди и буферы сетевого стека; пересчитать лимит соединений СУБД с учётом числа процессов PHP-FPM и ограничить число этих процессов на сервер. Серверу БД рекомендовали добавить сетевые интерфейсы — это ответ на узкое место во внутренней сети.
- Передача результатов. Заказчик получил отчёт с моделью нагрузки, результатами, выводами и рекомендациями, а также HTML-отчёты JMeter по стабильному и двум стресс-тестам, сырые логи, тест-план, датасет пользователей и тест регистрации. С этими материалами тесты можно повторить. По итогам провели встречу по применению рекомендаций по конфигурации.
“
Нагрузочное тестирование — ключ к уверенности в стабильной работе высоконагруженных систем. Важно не только выявить узкие места, но и предложить клиенту оптимальные пути их решения.
Обсудить проект _
Если у вас есть ИТ-проблема, оставьте свои контакты, и мы поможем спланировать ее решение. Обещаем не рассылать спам.
Нажимая, я говорю «Да» конфиденциальности и соглашаюсь с обработкой персональных данных
Контакты _
