Команда «Перфоманс Лаб» регулярно работает в условиях сжатых сроков, ограниченных ресурсов и недостаточно четких бизнес-требований.
В таких ситуациях особенно важны гибкость, быстрая адаптация, грамотное распределение ресурсов и поиск нестандартных решений.
В этом кейсе мы расскажем, как на практике справляемся с такими вызовами.
О проекте
Клиент:
Продукт:
Цель:
Задачи:
- Провести тестирование на поиск максимальной производительности плееров
- Настроить распределенную нагрузку с генераторов в сжатые сроки
- Выдать рекомендации по выбору плеера
- Передать компетенции заказчику
Реализация проекта
Аудит системы
Настройка распределенной нагрузки на JMeter
Сценарии нагрузочного тестирования включали
- Открытие главной страницы (Целевые показатели: 30000 RPS)
- Открытие главной страницы с плеером → прогрузка frontend части плеера (Определить максимальную производительность и ключевые показатели, Целевые показатели: 30000 пользователей в потоке)
- Открытие главной страницы с плеером → прогрузка frontend части плеера → получение первого кадра из потока (Определить максимальную производительность и ключевые показатели, Целевые показатели: 30000 пользователей в потоке)
Нагрузочное тестирование
Выбор видеоплеера
Отчетность и передача знаний
Нюансы проекта и наши решения
Проблемы в процессе тестирования
Проблема №1
При тестировании видеопотока уперлись в ограничение пропускной способности сетевого интерфейса. Решить проблему в рамках доступной инфраструктуры не удалось — это стало пределом для дальнейшего масштабирования и зафиксировано как ограничение тестирования.
Проблема №2
Столкнулись с неравномерным распределением трафика через Nginx. Нагрузка концентрировалась на отдельных узлах.
Решение: заменили Nginx на физические HAProxy и убрали балансировку с маршрутизатора — перераспределение нагрузки стало стабильным и предсказуемым.
Некорректные бизнес требования, приводящие к рискам
Как эксперт легко избегает ошибок: всё начинается с правильных вопросов
Пример:
Заказчик обращается с запросом:
«Нам нужно 30 000 RPS на стриминговый сервис».
Технически это звучит как серьезная нагрузка — 30 000 запросов в секунду. Инженеры начинают проектировать систему, представляя себе десятки тысяч пользователей, одновременно генерирующих активные действия: обновление страницы, переподключение к трансляции и так далее.
На этом этапе нам достаточно задать один уточняющий вопрос:
«Что конкретно имеется в виду под 30 000 RPS?»
В нашем случае сразу выяснилось, что речь шла вовсе не о пиковой активности, а о 30 000 одновременных зрителях, которые просто смотрят трансляцию. Это другая нагрузка: запросы поступают равномерно, без резких всплесков, и система испытывает гораздо меньшую нагрузку, чем предполагалось вначале.
Вывод:
Корректное понимание задачи на старте существенно влияет на ход всего нагрузочного тестирования. Уточнение исходных требований помогает избежать ошибочных предположений, переоценки нагрузки и неэффективного использования ресурсов. Нам удалось избежать ошибок и сразу же вывести стратегию тестирования в правильное направление.
Результаты тестирования
Итоги проекта
Благодаря проведенному аудиту и нагрузочному тестированию:
- Подтверждена возможность работы сайта при 30 000 RPS;
- Выбраны наиболее подходящие видеоплееры с рекомендациями по их внедрению;
- Подготовлен отчет с детальным разбором результатов тестирования;
- Проведена передача знаний заказчику для дальнейшего мониторинга и оптимизации системы.
По результатам нагрузочного тестирования команда «Перфоманс Лаб» рекомендовала Заказчику решение для доставки контента от одного из российских разработчиков ПО. Платформа успешно выдерживает нагрузку в 100 000 одновременно подключённых пользователей, при этом соблюдая все нефункциональные требования.
