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

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

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

Ответ 1

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

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

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

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

удача в запуске

Ответ 2

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

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

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

Ответ 3

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

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

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

Ответ 4

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

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

Ответ 5

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

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

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

2) Код в некоторых ограничениях "Высокая загрузка"

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

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

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

Linux Format сделал хорошую статью на тему "Как выжить в slashdotting"... которую я нашел полезным в прошлом. Он доступен онлайн как PDF

Ответ 6

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

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

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

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

Ответ 7

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