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

Question

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

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

Answer 1

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

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

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

Существует отличный подкаст с высокой масштабируемостью на software engineering radio on the design of the new Guardian website, когда все успокаивается.

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

Answer 2

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

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

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

Answer 3

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

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

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

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

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

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

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

Формат Linux сделал хорошая статья о том, «Как выжить в slashdotting» ... которую я нашел полезным в прошлом. Это available online as a PDF

Answer 4

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

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

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

Answer 5

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

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

Answer 6

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

Answer 7

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

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

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

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