Как подготовить сайт к лавине посетителей...

Начало осени — почти как Новый год: во всех сферах происходит резкое и мощное оживление деловой активности. Казалось бы, это повод для радости, но для некоторых интернет-ресурсов рост нагрузки становится большой проблемой: сайт «падает» или тормозит, клиенты не могут оформить заказ и уходят к конкурентам. Причем происходит это вовсе не из-за DDoS-атак, причины более прозаические: запуск масштабных рекламных кампаний, рассылок сразу по всем каналам, горячий сезон для товаров или услуг. 

Вместо предисловия: договаривайтесь

Готовиться к рекламной кампании заранее нужно не только отделу маркетинга и отделу продаж. Еще важнее, чтобы к наплыву трафика успел подготовиться технический отдел. В истории известны случаи, когда маркетологи устраивали «DDoS» своему сайту за деньги из своего же рекламного бюджета, не предупредив технических специалистов о запуске новой крутой акции. Поэтому даже не столько совет, сколько просьба: не забывайте согласовывать такие вещи заранее между всеми членами команды. Один час даунтайма магазину с оборотом 300 миллионов рублей в год стоит 34 тысячи рублей.

Масштабируемся в «облаках»

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

Плюс данного решения, помимо денежной экономии, в том, что со стороны разработки готовить проект к такой схеме практически никогда не требуется. В каждый конкретный момент времени проект работает только с одного сервера, что значительно облегчает поддержку. Минус решения в том, что мощные облачные хостинги располагаются, в основном, за рубежом, а российские «облака» предлагают максимум до 24-х ядер процессора на один сервер в принципе. Это едва ли выше типового хостингового предложения. Использовать зарубежные площадки не всегда возможно в связи с законом «О персональных данных», поэтому «облака» помогут не каждому проекту.

Кэшируйте лендинги

Обычно все резкие всплески посещаемости направлены на какую-то одну конкретную точку на сайте. Это может быть страница с рекламной акцией, сенсационная новость (если речь идёт о СМИ), свежий ролик популярного блогера на видео-сервисе. В любом случае, «страдают» всего одна-две странички, не более. И можно серьезно минимизировать наносимый такими запросами ущерб, жёстко закешировав наиболее «горячие точки». Важно, чтобы на таких страницах не было привязки к регистрации и авторизации пользователя, чтобы страница была единой для всех. Кэш поможет сдержать первый удар, а дальше нагрузка будет распределена уже более плавно. Новость, например, можно оформить в отдельную статическую html-страницу — веб-сервер nginx сможет отдавать ее напрямую со скоростью света без особого ущерба для производительности всей системы.

Отправляем рассылки плавно

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

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

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

Не жалейте ресурсы

Вариант перейти на тариф подороже с более мощным «железом» — это неплохой вариант для планирования роста нагрузки. Вдруг ваша рекламная кампания пройдет так хорошо, что «регулярный» трафик вырастет на 20-30%? Или следом за одной кампанией маркетологи придумают без остановки следующую? А может быть, ваш проект уже давно перерос VPS и заслуживает апгрейда? Железные ресурсы не стоит экономить, проект не должен работать «впритык».

И напоследок

Советы общего плана, которые могут быть полезны практически в любой ситуации:

• max_connections в настройках бд, в общем случае лучше больше, чем меньше;
• не стесняйтесь хотя бы немного крутить настройки сети sysctl. Включаем syncookies, tw_reuse, отсыпаем больше somaxconn;
• не перекладывайте ответственность за устранение аварий на сайте на одного человека, заручитесь поддержкой двух, а лучше трех специалистов, готовых оперативно приступить к «починке» системы в случае аварии. Минимизируйте влияние «человеческого фактора».

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