Лучшие практики для противостояния трафику в день запуска

Question

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

Подробности: это стек L/A/M/PHP, использующий внутреннюю инфраструктуру MVC. В настоящее время он запускается на одном сервере с Apache и MySQL на обоих, но мы можем разбить его, если потребуется. Мы уже устанавливаем memcached и делаем столько кэширования на уровне PHP, сколько можем себе представить. Некоторые страницы довольно интенсивно выполняют запросы, и мы используем Smarty в качестве нашего движка шаблонов. Имейте в виду, что нет времени менять какой-либо из этих основных аспектов - это всего лишь настройка. На какие вещи мы должны обращать внимание?

Answer 1

Сначала измерьте, затем оптимизируйте. Вы сделали какой-нибудь нагрузочный тест? Где узкие места?

Как только вы узнаете свои узкие места, тогда вы сможете разумно решить, нужны ли вам дополнительные блоки БД или веб-блоки, сейчас вы просто догадаетесь.

Кроме того, как ваши результаты тестирования загрузки сравниваются с ожидаемым трафиком? Можете ли вы справиться с 2x ожидаемым трафиком? 5x? Как легко / быстро вы можете приобрести и выпустить дополнительное оборудование? Я уверен, что бизнес-требование должно состоять в том, чтобы не дать сбой во время запуска, поэтому убедитесь, что у вас есть лот доступной емкости, вы всегда можете освободить ее после того, как нагрузка стабилизируется и вы знаете, что вам нужно. *

Answer 2

Я бы хотя бы вычеркнул весь статический контент. Установите другой vhost где-нибудь еще и загрузите на него все графические файлы / css / js. Вы можете купить несколько дополнительных циклов разгрузки контента этого типа контента. Если вас это действительно беспокоит, вы можете зарегистрироваться и воспользоваться службой распространения контента. Сейчас есть много похожих на Akamai и довольно дешевых.

Другая идея может заключаться в том, чтобы использовать apache mod_proxy для сохранения сгенерированного вывода страницы в течение определенного промежутка времени. APC также вполне пригоден для использования. Вы можете использовать захват буферизации вывода + время последнего изменения связанных данных на странице и использовать кэшированную версию APC. Если страница больше не действительна, вы регенерируете и снова сохраняете в APC.

Удачи, это будет опыт обучения!

Answer 3

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

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

Answer 4

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

1) Используйте недорогой инструмент, такой как https://browsermob.com/, для нагрузочного тестирования вашего сайта. Как минимум, вы должны смотреть на 100 000 уникальных посетителей в час. Если вы получаете рекламу с домашней страницы MSN, позаботьтесь о том, чтобы обрабатывать 500 000 уникальных сообщений в час.

2) Переместить весь статический графический / видео контент в CDN. Edgecast и Amazon - два отличных варианта.

3) Используйте Jet Profiler для профилирования сервера MySQL для анализа любых медленно выполняющихся запросов. Незначительные изменения могут иметь огромные преимущества.

Answer 5

Я бы лично сделал несколько вещей

1) Установите систему балансировки нагрузки / репликации базы данных

Это означает, что ваша служба может распространяться на несколько серверов. Не можете позволить себе иметь более одного сервера постоянно? Используйте Amazon E3 - это хорошо для размещения подобных вещей (включите еще несколько серверов, чтобы справиться с нагрузкой)

2) Код с некоторыми ограничениями «высокой нагрузки»

Например, если ваш поиск неэффективен - отключите его, когда нагрузка достигнет определенного уровня. «Извините, мы заняты, попробуйте позже для поиска»

3) Нагрузочный тест ... Используйте что-то вроде ApacheBench для стресс-тестирования ваших серверов.

4) Лично я считаю, что лучше отключить «Keep-Alive» Connections. Это может немного снизить общую производительность, но - это означает, что вместо того, чтобы что-то, где сайт работает хорошо для нескольких человек, а другие получают тайм-ауты, каждый получает несогласованный сервис, если он достигает этого уровня

Linux Format сделал хорошую статью на тему «Как пережить косую черту» ... которую я нашел полезной в прошлом. Это доступно онлайн как PDF

Answer 6

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

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

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

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

удачи на старте

Answer 7

Изучите использование Varnish - это кеширующий обратный прокси-сервер (например, squid, но гораздо более универсальный). Я управлял несколькими довольно большими сайтами за этим, это, казалось, работало действительно хорошо.