В IT-среде до сих пор живуч стереотип, что нагрузочное тестирование нужно исключительно, чтобы узнать максимальную пропускную способность инфраструктуры. И что нагрузочное делается либо перед масштабной акцией типа Чёрной пятницы, либо после того, как сайт всё-таки не выдержал и упал — чтобы узнать, при каком RPS это произошло.

Однако само по себе знание текущего предельного RPS не даст вам ничего. Да и смысл проводить нагрузочное тестирование ПОСЛЕ аварии, конечно, есть, но гораздо рациональнее сделать его ДО неё. Чтобы она даже не случилась. А уж когда речь идёт не просто об ожидаемой лавине трафика, а о том, что эта лавина хлынет на новую инфраструктуру… Словом, вот в меру захватывающая история о том, как нагрузочное тестирование помогло одному из крупнейших ритейлеров, компании Fix Price, переехать без боли, пожара и бессонных ночей.

Для начала несколько слов про саму компанию. У неё почти 5,5 тысячи розничных магазинов в России и странах СНГ, так что название и логотип знакомы, без преувеличения, каждому читателю этой статьи. Но помимо оффлайновой сети есть сайт с доставкой, личным кабинетом пользователя и электронным каталогом. До недавнего момента основная нагрузка лежала на платформе Битрикс (fix-price.ru), но в 2020 году начались работы по созданию собственной платформы fix-price.com.

«Проект начался почти 2 года назад. Вначале мы тщательно спланировали новую платформу, оценили с точки зрения бизнес-метрик, состава необходимой команды и перспектив развития. Далее последовало несколько итераций MVP.

Результаты последних тестов и анализ проблем во время масштабных маркетинговых акций, перед переключением основного трафика на новую платформу показали, что мы не всегда выдерживаем нагрузку. Поэтому о полном переключении не могло идти и речи.

Мы связались с ITSumma, так как знали, что у них есть большая экспертиза в построении высоконагруженных инфраструктур и нагрузочном тестировании. Задача была в том, чтобы провести performance-тесты системы и понять, что именно идет не так при большом трафике и как это исправить».

Олег Лексин, начальник IT-службы Fix Price.


Как мы проводили нагрузочное тестирование


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

Оно проводилось по 4 сценариям, в каждом мы выполнили две итерации для обеих мобильных платформ — iOS и Android:
  1. Сценарий захода на страницу категории.
  2. Сценарий получения адресов магазинов.
  3. Сценарий применения фильтров по товару.
  4. Сценарий авторизации.

Ранее проблемы появлялись во время масштабных маркетинговых активностей. Поэтому профили нагрузки для тестирования выбирались, чтобы оценить предполагаемые слабые зоны системы.

Некоторые из результатов тестирования приведены ниже.



Тесты 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

Комментарии (0)