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

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

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

Чтобы не повторять подобных ошибок готовиться к распродажам стоит основательно и со всех сторон.

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

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

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

Систем мониторинга сети и ИТ инфраструктуры существует достаточно много, как с открытым исходным кодом так и платных, наиболее популярные из них: Nagios и Zabbix.

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

Илья Безрукавников
Руководитель департамента DevOps Интаро

На одном из наших крупных проектов мы внедрили систему мониторинга, которая покрывает исчерпывающее количество метрик. Проблемы разделены на несколько типов критичности: от типа при котором в системе мониторинга остается пометка, до типа при котором начинает работать система эскалации для оповещения ответственного администратора. Эскалация работает следующим образом: изначально администратору приходит сообщение в мессенджер, если администратор не отреагировал, на его номер телефона отправляется СМС-уведомление. Если и после СМС к решению проблемы не приступили, система производит телефонный звонок на мобильный администратора. Таким образом ни одна проблема не останется незамеченной.

Следующим шагом логично провести «проверку боем», то есть нагрузочным тестированием.

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

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

Здесь стоит оговориться, что план нагрузочного тестирования должен быть детально проработан. Т.к. нагрузочные тесты в таких ситуация проводят на «боевом» проекте нужно четко обозначить границы его остановки. Если не уделить этому моменту должного внимания, то нагрузочный тест легко превратить в DOS — атаку, с последующим отказом в обслуживании. Очевидно, что если проект уже работает нестабильно, то стоит отказаться от нагрузочных тестов и вернуться к ним тогда, когда у проекта появится запас производительности (собственно, то что мы и хотим измерить).

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

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

В классическом веб-проекте можно выделить 3 основных роли (функциональных узла):

• Сервер приложения: выполняет бизнес-логику проекта (код).

• Веб-сервер: выполняет обработку запросов от пользователей, отдает и кэширует статический контент (картинки, стили, javascript и т.д.) и распределяет нагрузку на серверы приложения в случае если их несколько.

• Сервер баз данных: хранит информацию и выполняет запросы к данным.

Можно выделить еще несколько ролей, таких как: кеш, поиск, регулярные задачи. Но на начальном этапе можно остановиться на 3 представленных выше.

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

По возможности стоит применять подход микросервисов. Например, если в классическом интернет-магазине сделать независимый от основной логики сервис поиска товаров, то в случае проблем с производительностью поиска сайт не лишается основного функционала — оформление заказов. (прим. Гамбит — пожертвовать малым ради большего :)) )

Для анализа производительности кода проекта потребуется настроить мониторинг его выполнения. По мониторингу можно понять, какой контекст выполнения кода тормозит. Например, долгая работа с кэшем, долгие запросы к БД, медленная обработка данных.

Далее следует произвести профайлинг кода для выяснения причин, по которым это происходит. Причинами могут быть отсутствующее, неэффективное или избыточное кэширование, запросы к БД с выборкой избыточных данных или банальное отсутствие индексов. Отдельное внимание стоит уделить непосредственной реализации функционала «в коде». Часто бывает так, что рефакторинг (переработка структуры) кода позволяет добиться значительного прироста производительности.

Илья Безрукавников
Руководитель департамента DevOps Интаро

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

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

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

Успешно проведенная Чёрная пятница это отличная возможность не только резко увеличить продажи, но и превратить этих сезонных покупателей в своих постоянных клиентов.

Так что если вы планируете сделать крутой интернет-проект и стать лидером рынка, качественно выполненная highload-оптимизация позволит вашему сайту выдержать пиковые нагрузки и достичь амбициозных целей.

Для оценки ситуации на вашем проекте оставьте заявку на аудит.

Чек-лист на проведение аудита

Базовый вариант:

• Если на проекте есть достаточный мониторинг: мы изучаем метрики и даем рекомендации по изменению архитектуры или указываем на узкие места.

• Если на проекте нет мониторинга:

  • Мы получаем доступ к серверам проекта

  • Покрываем серверы мониторингом

  • Собираем исторические данные в течении малого промежутка времени

  • Даем рекомендации по изменению архитектуры или указываем на узкие места.

Расширенный вариант:

• Мы покрываем весь проект мониторингом по исчерпывающему количеству метрик

• Анализируем полученные данные

• Устраняем «явные» узкие места в конфигурации серверов

• Если требуется производим профайлинг кода с рекомендациями по рефакторингу

• После применения рекомендаций оцениваем результат

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

• Последний этап (опционально): сопровождение проекта.

Оригинал: https://intaro.ru/blog/highload_audit