Нагрузочное тестирование

Проверим вашу инфраструктуру на отказоустойчивость при многократном росте трафика. Вы получите детальный отчёт и рекомендации по устранению проблем. Масштабируйте свои веб-сервисы и предотвращайте аварии — без простоев и финансовых потерь.

Fixprice
Tass
S7
Tilda
Askona
Habr
Lenta
Action
Что это и зачем нужно?

Нагрузочное тестирование — это контролируемое испытание инфраструктуры на отказоустойчивость при многократном росте нагрузки.

Когда необходимо нагрузочное тестирование

Аварийный инцидент

Чтобы понять причину, по которой инфраструктура не справилась с ростом трафика.

Увеличение посещаемости

Чтобы выяснить, почему органический рост посещаемости ресурса замедляет работу сайта.

Приёмка проекта

Убедиться, что проект, разработанный сторонним подрядчиком, надёжен и выдержит запланированные нагрузки.

Ввод новой инфраструктуры в эксплуатацию

Для проверки «запаса прочности» новой инфраструктуры до выкладки на боевые сервера.

Подготовка к высокому сезону

Для уверенности накануне крупной акции или распродажи, что сайт справится со всплеском нагрузки.

robot

Как проходит тестирование

15-летний опыт работы с техподдержкой b2c/b2b-сервисов и e-commerce проектов позволил нам выработать наилучший сценарий проведения нагрузочного тестирования:

15-летний опыт работы с техподдержкой b2c/b2b-сервисов и e-commerce проектов позволил нам выработать наилучший сценарий проведения нагрузочного тестирования:

🤚️Вы можете перетягивать таймлайн
Сбор требований к пропускной способности инфраструктуры
1
Формирование сценариев на основе анализа пользовательских запросов к сайту/приложению
2
Подбор наиболее подходящих под потребности вашего проекта инструментов (JMeter, Яндекс.Танк, Gatling, инструменты собственной разработки)
3
Проведение нескольких итераций нагрузочного тестирования, по итогу каждой из которых будут сформированы детальные рекомендации по модификации инфраструктуры
4
Составление итогового отчета с информацией о результатах тестирования и рекомендациями по исправлению проблем
5

Технологии, которые мы используем

Мониторинг и системы визуализации

Prometheus, Grafana, TICK Stack, Zabbix, Nagios, Icinga, DataDog, NewRelic

Системы управления инцидентами

PagerDuty, Amixr

Логирование, отслеживание ошибок

ELK, EFK, Grafana Loki, Graylog, Sentry

Системы трассировки

Jaeger, Zipkin

Web, ingress и серверы приложений

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

Системы автоматизации, CI/CD

Jenkins, Gitlab CI, CircleCI, Travis CI, Bitbucket Pipelines, TeamCity, GoCD, ArgoCD, Spinnaker

Облачные системы автоматизации, CI/CD

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 улучшить стабильность сайта

lamp

Клиент

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.


lamp

Можно дополнить услугами

Тестирование системы изнутри закрытого контура
+ 150 000 ₽

к общей стоимости тестирования, в них входят организация стенда и инсталляция инструментов нагрузочного тестирования внутри контура.

Четвёртая и последующие итерации тестирования
от 50 000 ₽

за каждую дополнительную итерацию, проведённую по желанию заказчика.

Настройка мониторинга
(При его отсутствии)
+ 60 000 ₽

к общей стоимости тестирования, в неё входит установка и конфигурация мониторинга, фиксирующего потребление ресурсов и использование сервисов.

Разработка ТЗ на изменение инфраструктуры по итогам тестирования
по запросу

к общей стоимости тестирования. Вы можете внести необходимые изменения самостоятельно или доверить это нашей команде инженеров.

Вопросы и ответы

Получается, после каждой аварии нужно проводить такую дорогостоящую процедуру?

Нагрузочное тестирование, которое проводится после аварии или сбоя, нацелено на поиск их причин. В полученном по результатам тестирования отчёте вы найдёте не только информацию «почему так произошло», но и рекомендации «как всё исправить». И количество критических инцидентов в результате многократно сократится.

Неужели перед каждым существенным апдейтом системы нужно проводить нагрузочное тестирование?

Всё зависит от сложности системы и величины потерь, которые вы понесёте в случае её длительного простоя. В нашем отчёте вы увидите потенциальные «слабые места» инфраструктуры. И сможете либо их скорректировать, либо, если текущая архитектура этого не позволяет, обратить внимание именно на них при выкатке апдейта и мониторить конкретные показатели.

А почему нужно обращаться к вам, если с «Яндекс. Танком» может совладать любой более-менее опытный айтишник?

«Яндекс.Танк»  — лишь один из инструментов, которые мы применяем. Но главное — «более-менее опытный айтишник» с его помощью даст вам лишь понимание, где проект может «сломаться». Тогда как наше тестирование, которое мы проводим выделенной командой в несколько итераций, даст вам знание, почему критический инцидент может произойти и как его не допустить.

Что делать, если выявленные проблемы мои специалисты не могут оперативно устранить собственными силами?

Наш продукт, в данном случае, — это отчёт, с информацией по состоянию системы и рекомендациями по устранению «слабых мест» и повышению отказоустойчивости. Но мы готовы провести данные работы силами наших специалистов, если у вас возникнет такая потребность.

Значит, теперь маркетологи не будут обвинять айтишников, что они не подготовили сайт к их суперской акции, а айтишники не будут обвинять маркетологов, что те их не предупредили о суперской акции?

Значит, теперь маркетологи не будут обвинять айтишников, что они не подготовили сайт к их суперской акции, а айтишники не будут обвинять маркетологов, что те их не предупредили о суперской акции?

Полезные термины

Performance testing

Тестирование производительности. Оно проводится для определения скорости работы информационной системы или её составляющих под определённой нагрузкой.

Load testing

Нагрузочное тестирование. Состоит в определении производительности и времени отклика информационной системы в ответ на внешний запрос. Задача нагрузочного тестирования — выяснить, соответствует ли производительность системы требованиям, установленным при её создании.

Downtime period

Время недоступности сервиса/период простоя. Чем больше период простоя — тем выше потери бизнеса. Задача нагрузочного тестирования — снизить время недоступности до незначительной величины или полного нуля.

Готовы обсудить проект?

Ответим на заявку в ближайшие 24 часа. А еще мы можем проконсультировать вас по телефону +7 800 555-91-99, электронной почте info@itsumma.ru или в Telegram-чате.

Свяжитесь со мной здесь
Свяжитесь со мной здесь
❗️Имя не может быть пустым
❗️Телефон не может быть пустым
❗️Email не может быть пустым