Рекомендации по противодействию всплеску трафика в день запуска

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

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

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

На радиопрограммистов о дизайне нового веб-сайта Guardian, когда все успокоится.

Удачи в запуске.

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

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

Кроме того, как результаты нагрузочного тестирования соотносятся с ожидаемым трафиком? Можете ли вы обрабатывать в два раза больше ожидаемого трафика? Пять раз? Насколько легко/быстро вы можете приобрести и выпустить дополнительное оборудование? Я уверен, что бизнес-требование состоит в том, чтобы не допустить сбоев во время запуска, поэтому убедитесь, что у вас есть много доступных ресурсов. Вы всегда можете отпустить его позже, когда нагрузка стабилизируется, и вы знаете, что вам нужно.

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

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

Удачи. Это будет опыт обучения!

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

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

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

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

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

2) Код в некоторых ограничениях "High Load"

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

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

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

В Linux Format есть хорошая статья «Как пережить слэшдоттинг»… которую я нашел полезной в прошлом. Он доступен в Интернете в формате PDF.

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

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

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

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

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

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