В IT-среде до сих пор живуч стереотип, что нагрузочное тестирование нужно исключительно, чтобы узнать максимальную пропускную способность инфраструктуры. И что нагрузочное делается либо перед масштабной акцией типа Чёрной пятницы, либо после того, как сайт всё-таки не выдержал и упал — чтобы узнать, при каком RPS это произошло.
Однако само по себе знание текущего предельного RPS не даст вам ничего. Да и смысл проводить нагрузочное тестирование ПОСЛЕ аварии, конечно, есть, но гораздо рациональнее сделать его ДО неё. Чтобы она даже не случилась. А уж когда речь идёт не просто об ожидаемой лавине трафика, а о том, что эта лавина хлынет на новую инфраструктуру… Словом, вот в меру захватывающая история о том, как нагрузочное тестирование помогло одному из крупнейших ритейлеров, компании Fix Price, переехать без боли, пожара и бессонных ночей.
Для начала несколько слов про саму компанию. У неё почти 5,5 тысячи розничных магазинов в России и странах СНГ, так что название и логотип знакомы, без преувеличения, каждому читателю этой статьи. Но помимо оффлайновой сети есть сайт с доставкой, личным кабинетом пользователя и электронным каталогом. До недавнего момента основная нагрузка лежала на платформе Битрикс (fix-price.ru), но в 2020 году начались работы по созданию собственной платформы fix-price.com.
«Проект начался почти 2 года назад. Вначале мы тщательно спланировали новую платформу, оценили с точки зрения бизнес-метрик, состава необходимой команды и перспектив развития. Далее последовало несколько итераций MVP.
Результаты последних тестов и анализ проблем во время масштабных маркетинговых акций, перед переключением основного трафика на новую платформу показали, что мы не всегда выдерживаем нагрузку. Поэтому о полном переключении не могло идти и речи.
Мы связались с ITSumma, так как знали, что у них есть большая экспертиза в построении высоконагруженных инфраструктур и нагрузочном тестировании. Задача была в том, чтобы провести performance-тесты системы и понять, что именно идет не так при большом трафике и как это исправить».
Олег Лексин, начальник IT-службы Fix Price.
Как мы проводили нагрузочное тестирование
Перед нами стояла задача выявить текущий порог допустимой нагрузки и составить рекомендации по улучшению стабильности и производительности системы на основе результатов тестирования.
Оно проводилось по 4 сценариям, в каждом мы выполнили две итерации для обеих мобильных платформ — iOS и Android:
- Сценарий захода на страницу категории.
- Сценарий получения адресов магазинов.
- Сценарий применения фильтров по товару.
- Сценарий авторизации.
Ранее проблемы появлялись во время масштабных маркетинговых активностей. Поэтому профили нагрузки для тестирования выбирались, чтобы оценить предполагаемые слабые зоны системы.
Некоторые из результатов тестирования приведены ниже.
Тесты iOS в первом сценарии показали, что скорость ответа снижается после 420 RPS.
А во втором сценарии — что замедление и ошибки появляются после 800 PRS.
Для сравнения: Android в первом сценарии показал снижение после 600 RPS
И после 1300 RPS — во втором сценарии.
Что же показало тестирование?
На сценариях 1, 2 и 4 основной проблемой стала медленная работа БД и рост нагрузки на сервер ecom-postgres-master.
Из-за этого наблюдались ошибки запросов в БД в контейнерах nginx-api-… И по трейсу ошибок они наблюдаются почти по всем URL, по которым проводилось тестирование.
Также ошибки в логи посылал сам PostgreSQL:
А БД большую часть времени заняты выполнением запросов:
Как следствие — ожидания коннекта к БД, а следовательно, и подвисания; поды nginx-api-… начинают попадать под лимиты и падают по ООМ.
На сценарии 3 (применение фильтров) проблемы наблюдались со стороны CRM, как на iOS, так и на Android. При выполнении запросов GET /buyer/v1/order/history наблюдалось скопление рабочих процессов fpm в ожидании ответа от CRM:
Нагрузочное решает, или Вот какие рекомендации получились по итогам
Проблему с медленной работой БД должна решить проверка таблицы PostgreSQL на наличие индексов, проверка чтения по слэйвам базы, и вынос механизма сессий из БД в redis/memcached.
Проблемы с подвисанием подов nginx-api-… должно поправить ускорение работы с БД, но в качестве временной экстренной меры можно выделить подам больше памяти, т.к на нодах ещё достаточно свободных ресурсов.
Проблема применения фильтров решается оптимизацией Postgres-crm или наращиванием ресурсов для Postgres-crm, чтобы улучшить быстродействие.
«ITSumma провела для нас несколько итераций нагрузочного тестирования. Они выявили проблемы и предложили решения. Часть из них мы применили почти сразу, и они помогли. Результатами и скриптами нагрузочного от ITSumma мы пользуемся до сих пор, чтобы спрогнозировать рост трафика, необходимость масштабирования платформы и когда нужно оценить стабильность новой функциональности.
После оценки инфраструктуры от ITSumma мы смогли переключиться на новую платформу без потерь: задача выполнена и цель достигнута».
Олег Лексин, начальник IT-службы Fix Price.
Что вам с этого всего?
Опыт, как известно, сын ошибок трудных. Так что вам, дорогие читатели, с этого всего — опыт, не отягощённый тяжёлой семейной историей. Вот полезные выводы, которые пригодятся каждому:
- Проверять инфраструктуру перед переездом и масштабными акциями с помощью нагрузочного тестирования — это правильная и полезная привычка. Она помогает на старте избежать большинства проблем.
- Performance-тестирование не только помогает устранить трудности со снижением скорости отклика, но и служит основой для плана по масштабированию. Кроме этого, его скрипты можно использовать в дальнейшем, чтобы проверить стабильность новой функциональности в проекте.
- Можно делать нагрузочное своими силами, но проще и быстрее обратиться к профессионалам, которые знают, как нужно сделать. Впрочем, так дела обстоят много где ещё.
Ну, а если вы хотите получить консультацию по конкретной проблемезадаче, просто напишите на consulting@itsumma.ru
Автор:
Lleortea
