Рекомендации по выдерживанию всплеска трафика в день запуска
Вопрос
Мы работаем над веб-сайтом для клиента, который (на этот раз), как ожидается, получит достаточное количество трафика в первый же день.Появляются пресс-релизы, люди пишут об этом в блогах и т.д.Я немного обеспокоен тем, что в первый же день мы упадем ниц.На какие основные моменты вы бы обратили внимание, чтобы убедиться (заранее, без учета реальных данных о трафике), что вы сможете оставаться на ногах после крупного запуска?
Подробные сведения:Это настоящий L/A/M/PHP
stack, использующий внутренне разработанный фреймворк MVC.В настоящее время это запускается на одном сервере с Apache и MySQL на нем, но мы можем разбить это, если потребуется.Мы уже устанавливаем memcached и выполняем столько кэширования на уровне PHP, сколько можем себе представить.Некоторые страницы требуют довольно большого количества запросов, и мы используем Smarty в качестве нашего шаблонизатора.Имейте в виду, что нет времени менять какой-либо из этих основных аспектов - это всего лишь настройка.На какие вещи нам следует обратить внимание?
Решение
Чтобы подготовить или обработать всплеск (или пиковую) производительность, я бы сначала определил, готовы ли вы с помощью простого тестирования производительности с помощью чего-то вроде jметр.
Его легко настроить и запустить, и он даст вам ранние показатели того, справитесь ли вы с ожидаемой пиковой нагрузкой.
Однако, учитывая ваши временные ограничения, другими шагами, которые следует предпринять, были бы подготовка статических версий контента, которые привлекут наибольшее внимание (например, пресс-релизы, если вы планируете выпустить их в день запуска).Также убедитесь, что вы наилучшим образом используете кэширование на стороне клиента (на 1 запрос меньше к вашему серверу может иметь решающее значение).Веб, уже разработанный для чрезвычайно высокой масштабируемости и эффективного использования, кэширование контента - ваш лучший друг в таких ситуациях.
На сайте есть отличный подкаст о высокой масштабируемости радио программной инженерии о дизайне нового веб-сайта Guardian когда все успокоится.
удачи на старте
Другие советы
Сначала измерьте, затем оптимизируйте.Вы проводили какое-нибудь нагрузочное тестирование?Где находятся узкие места?
Как только вы узнаете свои узкие места, вы сможете разумно решить, нужны ли вам дополнительные блоки базы данных или веб-блоки, прямо сейчас вам остается только гадать.
Кроме того, как результаты вашего тестирования нагрузки соотносятся с ожидаемым трафиком?Можете ли вы обработать в 2 раза больше ожидаемого трафика?5x?Насколько легко / быстро вы можете приобрести и выпустить дополнительное оборудование?Я уверен, что бизнес-требование состоит в том, чтобы не допустить сбоя во время запуска, поэтому убедитесь, что у вас есть Лоты при имеющейся мощности вы всегда можете освободить его впоследствии, когда нагрузка стабилизируется и вы будете знать, что вам нужно.
Я бы, по крайней мере, исключил весь статический контент.Настройте другой vhost где-нибудь в другом месте и загрузите на него всю графику / css / js.Вы можете купить несколько дополнительных циклов, чтобы разгрузить подачу контента такого типа.Если вы действительно обеспокоены, вы можете зарегистрироваться и воспользоваться сервисом распространения контента.Сейчас есть много похожих на Akamai и довольно дешевых.
Другой идеей может быть использование apache mod_proxy для сохранения выходных данных сгенерированной страницы в течение определенного периода времени.APC также был бы вполне пригоден для использования..Вы могли бы использовать захват буферизации вывода + время последнего изменения связанных данных на странице и использовать кэшированную версию APC.Если страница больше не действительна, вы снова создаете ее заново и сохраняете в APC.
Удачи, это будет полезный опыт!
Проведите период бета-тестирования, в течение которого вы допускаете столько пользователей, сколько сможете обработать, измеряете производительность вашего сайта, устраняете ошибки, прежде чем начать работу.
Вы можете явно контролировать количество пользователей либо в закрытом бета-тестировании, либо в полупубличном бета-тестировании в стиле Google, где у каждого пользователя есть определенное количество рефералов, которые он может предложить своим друзьям.
Лично я бы сделал несколько вещей
1) Внедрить какую-нибудь систему балансировки нагрузки / репликации базы данных
Это означает, что вы можете распределить свой сервис по нескольким серверам.Не можете позволить себе иметь более одного сервера постоянно?Используйте Amazon E3 - он хорош для создания подобных приложений (включите еще несколько серверов для обработки нагрузки).
2) Код с некоторыми ограничениями "Высокой нагрузки"
Например, если ваш поиск неэффективен - отключите его, когда загрузка достигнет определенного уровня."Извините, мы заняты, повторите попытку поиска позже".
3) Нагрузочный тест...Используйте что-то вроде ApacheBench - верстак для стресс-тестирования ваших серверов.
4) Лично я считаю, что лучше отключить соединения "Keep-Alive".Это может немного снизить общую производительность, но это означает, что вместо того, чтобы сайт хорошо работал для нескольких человек, а остальные получали тайм-ауты, все получают несогласованный сервис, если он достигает этого уровня
Linux Format опубликовал хорошую статью на тему "Как выжить при слэшдоттинге"...который я находил полезным в прошлом.Это доступно онлайн в формате PDF
Основные первые шаги по настройке вашего сайта для обеспечения высокой посещаемости.
1) Используйте недорогой инструмент, такой как https://browsermob.com/ чтобы загрузить-протестируйте свой сайт.Как минимум, вы должны просматривать 100 тысяч уникальных посетителей в час.Если вы получаете рекламу с домашней страницы MSN, рассчитывайте на то, что сможете обрабатывать 500 тысяч уникальных запросов в час.
2) Переместите весь статический графический / видеоконтент в CDN.Edgecast и Amazon - два отличных варианта.
3) Используйте Jet Profiler для профилирования вашего сервера MySQL для анализа любых медленно выполняющихся запросов.Незначительные изменения могут иметь огромные преимущества.
Посмотрите на использование Лак- это кэширующий обратный прокси-сервер (похожий на squid, но гораздо более специализированный).Я запустил несколько довольно крупных сайтов, и мне показалось, что это работает действительно хорошо.