Нагрузочное тестирование
Проверим вашу инфраструктуру на отказоустойчивость при многократном росте трафика. Вы получите детальный отчёт и рекомендации по устранению проблем. Масштабируйте свои веб-сервисы и предотвращайте аварии — без простоев и финансовых потерь.
Что это и зачем нужно?
Когда необходимо нагрузочное тестирование
Аварийный инцидент
Чтобы понять причину, по которой инфраструктура не справилась с ростом трафика.
Увеличение посещаемости
Чтобы выяснить, почему органический рост посещаемости ресурса замедляет работу сайта.
Приёмка проекта
Убедиться, что проект, разработанный сторонним подрядчиком, надёжен и выдержит запланированные нагрузки.
Ввод новой инфраструктуры в эксплуатацию
Для проверки «запаса прочности» новой инфраструктуры до выкладки на боевые сервера.
Подготовка к высокому сезону
Для уверенности накануне крупной акции или распродажи, что сайт справится со всплеском нагрузки.
Как проходит
тестирование
15-летний опыт работы с техподдержкой b2c/b2b-сервисов и e-commerce проектов позволил нам выработать наилучший сценарий проведения нагрузочного тестирования:
15-летний опыт работы с техподдержкой b2c/b2b-сервисов и e-commerce проектов позволил нам выработать наилучший сценарий проведения нагрузочного тестирования:
Технологии, которые мы используем
Prometheus, Grafana, TICK Stack, Zabbix, Nagios, Icinga, DataDog, NewRelic
PagerDuty, Amixr
ELK, EFK, Grafana Loki, Graylog, Sentry
Jaeger, Zipkin
Nginx, Envoy, Linkerd, Traefik, Apache, HAProxy, Jetty, Tomcat, NodeJS
Python, TypeScript, JavaScript, Go, Java, PHP, Ruby, Erlang
Amazon AWS, Google Cloud Platform, Microsoft Azure, Rackspace, Alibaba Cloud, Yandex Cloud, Selectel, Cloud.ru
Docker, CRI-O, LXC, LXD
Kubernetes, Nomad, Docker Swarm, RedHat OpenShift, Mesos/Marathon
Jenkins, Gitlab CI, CircleCI, Travis CI, Bitbucket Pipelines, TeamCity, GoCD, ArgoCD, Spinnaker
AWS CodePipeline, AWS CodeDeploy, AWS CodeCommit, Google CloudBuild, Spinnaker
AWS RDS and other DBs, Google Cloud SQL and other DBs, Firebase, MongoDB Atlas
Результат
Команда и цена
Срок проведения
От двух недель
От чего зависит
На итоговую стоимость услуги влияют следующие параметры инфраструктуры:
- Стек ПО
- Количество итераций тестирования
- Типы эмулируемой нагрузки
- Количество узлов
Кто будет в команде
Каждый раз мы формируем команду индивидуально. Количество выделяемых специалистов зависит от параметров инфраструктуры. Но в команду всегда входят:
- Менеджер проекта
- DevOps-инженер
- Системный архитектор
- Технический писатель
- Техлид проекта
- Специалист по системам мониторинга
Примеры
Типовой кейс
Тестирование ecommerce-сайта
Сценарии: Анонимный трафик на страницы, прохождение основного бизнес-процесса полностью (например, заказ товара или услуги), регистрация, работа под зарегистрированным пользователем.
Порядок действий:
- Первая итерация — проводим тестирование, указываем узкие места, составляем первичный отчет.
- Вторая итерация — заказчик вносит изменения согласно рекомендациям первичного отчета, мы дорабатываем сценарии, проводим тестирование.
- Финальная итерация — составляем итоговый отчет с описанием результатов каждого этапа и предоставляем рекомендации по дальнейшей (некритичной) оптимизации инфраструктуры.
Нетиповой кейс
Тестирование пропускной способности ETL-системы/стресс-тестирование базы данных
Сценарии: Измерение способности системы выдерживать заданное количество запросов. Если у системы имеется rest api, тестирование проводится при помощи jmeter.
Порядок действий:
- Мы проводим необходимое количество итераций нагрузочного тестирования согласно вводным от заказчика и выдаем клиенту итоговые результаты и отчет.
- Количество итераций зависит от характеристик проекта и задач заказчика и всегда определяется индивидуально.
Как нагрузочное тестирование помогло FixPrice улучшить стабильность сайта
Клиент
FixPrice — сеть магазинов доступных товаров для дома. Точнее их сайт, где можно заказать доставку товаров и приобрести их удаленно.
В 2020 клиент решил переехать с Битрикса на собственную платформу.Нас он привлек на финальном этапе, чтобы улучшить стабильность своей инфраструктуры.
Задача
Выявить текущий порог допустимой нагрузки и составить рекомендации по улучшению стабильности системы на основе результатов тестирования.
Проблемы возникали в 4 пользовательских сценариях:
- Заход на страницу категории товара;
- Получение пользователем адресов магазинов;
- Применение фильтров по товару;
- Авторизация.
Что показало тестирование?
В сценариях 1, 2 и 4 основной проблемой стала медленная работа БД и рост нагрузки на мастер-сервер Postgre.
В сценарии 3 проблемы наблюдались со стороны CRM. При выполнении запросов наблюдалось скопление рабочих процессов fpm (fast process manager) в ожидании ответа от CRM.
Наши рекомендации
- Проверить таблицу PostgreSQL на наличие индексов, проверить чтение по слэйвам базы и вынести механизм сессий из БД в redis/memcached.
- Ускорить работу с БД, но в качестве временной экстренной меры можно выделить подам больше памяти, т.к. на нодах ещё достаточно свободных ресурсов.
- Оптимизировать Postgre-crm или нарастить ресурсы для Postgre-crm, чтобы улучшить быстродействие.
Слово клиенту
“ Результатами и скриптами нагрузочного от ITSumma мы пользуемся до сих пор, чтобы спрогнозировать рост трафика, необходимость масштабирования платформы и когда нужно оценить стабильность новой функциональности. После тестирования инфраструктуры от ITSumma мы смогли переключиться на новую платформу без потерь”, —
Олег Лексин
руководитель IT-службы Fix Price.
Можно дополнить услугами
Вопросы и ответы
Нагрузочное тестирование, которое проводится после аварии или сбоя, нацелено на поиск их причин. В полученном по результатам тестирования отчёте вы найдёте не только информацию «почему так произошло», но и рекомендации «как всё исправить». И количество критических инцидентов в результате многократно сократится.
Всё зависит от сложности системы и величины потерь, которые вы понесёте в случае её длительного простоя. В нашем отчёте вы увидите потенциальные «слабые места» инфраструктуры. И сможете либо их скорректировать, либо, если текущая архитектура этого не позволяет, обратить внимание именно на них при выкатке апдейта и мониторить конкретные показатели.
«Яндекс. Танк» — лишь один из инструментов, которые мы применяем. Но главное — «более-менее опытный айтишник» с его помощью даст вам лишь понимание, где проект может «сломаться». Тогда как наше тестирование, которое мы проводим выделенной командой в несколько итераций, даст вам знание, почему критический инцидент может произойти и как его не допустить.
Наш продукт, в данном случае, — это отчёт, с информацией по состоянию системы и рекомендациями по устранению «слабых мест» и повышению отказоустойчивости. Но мы готовы провести данные работы силами наших специалистов, если у вас возникнет такая потребность.
Нагрузочное тестирование не гарантирует 100-процентного влияния на коллектив, но обычно степень дружелюбия и градус позитива после него ощутимо вырастают!
Полезные термины
Performance testing
Тестирование производительности. Оно проводится для определения скорости работы информационной системы или её составляющих под определённой нагрузкой.
Load testing
Нагрузочное тестирование. Состоит в определении производительности и времени отклика информационной системы в ответ на внешний запрос. Задача нагрузочного тестирования — выяснить, соответствует ли производительность системы требованиям, установленным при её создании.
Downtime period
Время недоступности сервиса/период простоя. Чем больше период простоя — тем выше потери бизнеса. Задача нагрузочного тестирования — снизить время недоступности до незначительной величины или полного нуля.
Ответим на заявку в ближайшие 24 часа. А еще мы можем проконсультировать вас по телефону +7 800 555-91-99, электронной почте info@itsumma.ru или в Telegram-чате.
