Как я могу обнаружить и выжить, будучи "Slashdotted"?

Какой хороший способ пережить аномально высокие пики трафика?

Я думаю, что по какой-то причине мой веб-сайт должен временно переключиться в режим "низкой пропускной способности": переключиться на базовые HTML-страницы, минимальную графику, отключить виджеты, которые могут создать ненужную нагрузку на базу данных, и т.д.

Мои мысли:

  • Контролировать использование процессора
  • Пропускная способность монитора
  • Мониторинг запросов в минуту

Я знаком с такими опциями, как кеширование, переключение на статический контент или сеть доставки контента и т.д. Как средство выживания, поэтому, возможно, следует сосредоточиться на том, как определить, когда веб-сайт будет перегружен. (Хотя ответы на другие методы выживания, конечно, все же приветствуются.) Допустим, веб-сайт работает под управлением Apache на Linux и PHP. Это, вероятно, самая распространенная конфигурация, и она должна позволить максимальному количеству людей получить помощь от ответов. Предположим также, что дорогостоящие варианты, такие как покупка другого сервера и балансировка нагрузки, недоступны - по крайней мере, для большинства из нас упоминание о Slashdot будет встречаться один раз в жизни, а не то, на что мы можем потратить деньги, готовясь к ,

ОТВЕТЫ

Ответ 1

  • Не указывайте никому URL
  • Постройте что-нибудь настолько бесполезное, что если правило 1 сломается, никто не придет.

Ответ 2

  • установить munin для отслеживания потребления нагрузки/памяти и т.д. и уведомлять о перегрузках.
  • установить monit для перезапуска apache2, если он сбой
  • установите nginx в качестве интерфейса apache2, он значительно уменьшит требования к памяти при большой нагрузке

Ответ 3

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

Я говорю из опыта того, что меня раскалывают. Это не забавно, когда вы не можете получить доступ к Интернету вообще, потому что тысячи людей одновременно пытаются загрузить фотографии компьютера, который ваш сосед по дому установлен в гриле Джорджа Формана. Никакое количество брандмауэров не спасет вас.

Ответ 4

Основы:

  • Не пытайтесь размещать сайты с большими объемами в Windows, если вы не являетесь истинным гуру Windows. Это можно сделать, но это вопрос времени и стоимости.
  • Используйте статический контент (т.е. никаких запросов к базе данных) везде, где вы можете.
  • Узнайте о заголовках кеша и правильно используйте их для изображений и других статических активов.
  • По крайней мере, используйте Apache, но если вы можете, используйте lighttpd или другой высокопроизводительный веб-сервер.

Реальные ответы:

  • Знайте свой SQL и тратите время на анализ медленных запросов. Большинство загрузок страниц не должны требовать больше, чем секунд прямых запросов.
  • Определите, где ваша нагрузка действительно. Если это медиа-сайт, подумайте о размещении контента в другом месте (например, Akamai или какой-либо другой сервис). Если это сайт с тяжелой базой данных, подумайте о репликации.
  • Знайте, какая репликация будет работать для вас. Если у вас есть сайт с высокой прочностью, стандартная репликация master/slave MySQL должна быть в порядке. Если у вас много записей, вам понадобится какая-то настройка с несколькими мастерами, например, MySQL Cluster (или расследовать репликацию "каскадирование" или "водопад" ).
  • Если вы можете, не вызывайте PHP - то есть кешированную статическую (HTML) копию страницы (это то, что делает большинство плагинов для Wordpress). Apache гораздо быстрее обслуживает статические файлы, чем даже самый простой мир hello PHP script.

Ответ 5

Вот довольно длинная, но очень информативная статья о выживших "вспышках".

Здесь их сценарий для ситуации, в которой предлагаются предлагаемые решения:

В этой статье мы рассмотрим вопрос о масштабировании в глазах персонажа, которого мы называем инноватором гаража. Новатор гаража творческий, технически подкованный и амбициозный. У нее отличная идея для "Следующей большой вещи" в Интернете и ее реализация, используя запасные серверы, сидящие в гараже. Служба работает и работает, время от времени привлекает новых посетителей и делает небольшой доход от рекламы и подписки. Когда-нибудь, возможно, ее сайт попадет в джек-пот. Возможно, он достигнет первой страницы Slashdot или Digg; возможно, Valleywag или New York Times упомянут об этом.

Наш новатор может получить только один выстрел в широко распространенная реклама. Если и когда случается, десятки тысяч людей посетит ее сайт. Поскольку ее идея так роман, многие станут приносящих доход клиентов и друзья. Но вспышка толпы заведомо непостоянный; результат не будет быть почти как идиллический, если сайт падает под его нагрузкой. Много людей не будет возвращаться, если сайт не работает в первый раз. Тем не менее, это трудно оправдать выплату десятков тысячи долларов за ресурсы на всякий случай, когда сайт испытывает внезапный всплеск нагрузки. Вспышки как гаражные новаторы, так и ее цель.

Один выход из этой головоломки с помощью современной утилиты вычислений.

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

Ответ 6

Я переписываю все URL-адреса, упомянутые несколькими популярными сайтами, перенаправленными через coralCDN.

Пример для Apache:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /

RewriteCond %{HTTP_USER_AGENT} !^Googlebot
RewriteCond %{HTTP_USER_AGENT} !^CoralWebPrx
RewriteCond %{QUERY_STRING} !(^|&)coral-no-serve$
RewriteCond %{HTTP_REFERER} ^http://([^/]+\.)?digg\.com [OR]
RewriteCond %{HTTP_REFERER} ^http://([^/]+\.)?slashdot\.org [OR]
RewriteCond %{HTTP_REFERER} ^http://([^/]+\.)?slashdot\.com [OR]
RewriteCond %{HTTP_REFERER} ^http://([^/]+\.)?fark\.com [OR]
RewriteCond %{HTTP_REFERER} ^http://([^/]+\.)?somethingawful\.com [OR]
RewriteCond %{HTTP_REFERER} ^http://([^/]+\.)?kuro5hin\.org [OR]
RewriteCond %{HTTP_REFERER} ^http://([^/]+\.)?engadget\.com [OR]
RewriteCond %{HTTP_REFERER} ^http://([^/]+\.)?boingboing\.net [OR]
RewriteCond %{HTTP_REFERER} ^http://([^/]+\.)?del\.icio\.us [OR]
RewriteCond %{HTTP_REFERER} ^http://([^/]+\.)?delicious\.com
RewriteRule ^(.*)?$ http://example.com.nyud.net/$1 [R,L]
</IfModule>

Ответ 7

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

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

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

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

Ответ 8

Я думаю, что предпосылка неверна: вы действительно очень хотите получить slashdotted, иначе у вас не будет веб-сайта в первую очередь. Гораздо лучший вопрос - как вы обрабатываете дополнительный трафик? И даже это действительно два вопроса:

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

Ответ 9

Реальный вопрос: "Какой самый эффективный способ быть Slashdotted"

Если это реальная проблема, перенаправьте трафик на мой сайт.

Ответ 10

Не записывайте контент или предоставляйте услугу, которая может понравиться вампирам;)

Ответ 11

Поместите его в облако!

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

В меньших масштабах использование CDN для всех ваших изображений/статического содержимого может помочь немного, опять же важно оценить цену. Amazon S3 - это CDN, о котором я слышу больше всего.

Ответ 12

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

Ответ 13

Никогда не становитесь популярными.

Пока это будет работать, это не очень полезно. Вам нужна инфраструктура, которая может масштабироваться очень коротко. Что-то вроде Google Gears или веб-сервисов Amazon кажется идеальным для этого, поскольку даже Slashdot не собирается подавлять Google или Amazon. Если вы хотите, чтобы ваш собственный сервер удостоверился, что ваш сетевой провайдер не собирается отключать вас при любом заданном пределе полосы пропускания. Покупайте достаточно оборудования, чтобы вы не напрягались, чтобы нести свой обычный трафик без каких-либо промахов, чтобы справляться с внезапными всплесками.

Ответ 14

Кэш... жесткий. Записывайте хиты, и если происходит всплеск, выпишите полностью статичную копию удаляемой страницы, а затем выполните это. Вырезание запросов БД от 100 до 2 с хорошей системой кеширования может выдержать слабую косая черта, но любые запросы БД все равно будут приводить к тому, что мертвый сайт находится под серьезной нагрузкой, к которой вы не готовы.

Ответ 15

Используйте кеширование!

Если вы используете WordPress (например), вы можете использовать что-то вроде WP-Super-Cache. Если вы используете обычный PHP, есть еще несколько вариантов, которые вы можете использовать, включая memcache. Или вы можете просто использовать обычное кэширование прокси-сервера squid.

Любое кэширование, которое вы используете, будет способствовать предотвращению (или slashdot/digg-proof) вашего сайта: -)

Ответ 16

Увеличьте уровень кэширования из БД, чтобы контент мог меня немного устареть, но быстрее получить доступ. Естественно, это применимо только в том случае, если содержание не должно быть на 100% непротиворечивым.

Ответ 17

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

Например, добавьте "UPDATE settings_table SET bandwidth = 'low';" в этот файл SQL и запустить его в mysql и сделать обратное, когда условия вернутся к нормальной работе.

Ответ 18

netstat -plant | awk '$4 ~ /:80\>/ {print}' | wc -l

Это покажет вам все подключения к серверу Apache. Вы можете создать cgi script, который рассчитает общее количество подключений к службе Apache и выдаст предупреждение после достижения определенного порога. Что делать в этот момент, это еще один вопрос.

Надеюсь, ваш сервер подготовлен.

Ответ 19

Я знаю, что с Digg вы можете связаться с ними и запросить их в черный список на своем сайте. Вероятно, вы можете сделать то же самое с Slashdot.

Ответ 20

Существует несколько способов сделать это или, по крайней мере, помочь. Найдите Google для "slashdot-proof", и вы найдете несколько из них:

  • Slashdot-proof ваш сервер с FreeCache - Boing Boing
  • Простые мысли Блог теперь Slashdot Доказательство

и др.

Ответ 21

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

На самом деле, это место не делает ТАКОГО плохо.

Ответ 22

Данные кэша.

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

Ответ 23

Автоматическое перенаправление на CDC Coral, если только запрос не отправлен из кораллового cdn.

Ответ 25

.htaccess:

RewriteEngine on
RewriteCond %{HTTP_REFERER} slashdot\.org [NC]
RewriteRule .* - [F]

Ответ 26

Одно слово: Knipex

Ответ 27

О выживании вы правы: переключите или переадресуйте ссылку на slashdotted на статическую html-страницу без графики. Возможно, вы захотите разместить эту страницу на другом веб-сервере, поэтому ваш исходный сервер не займет слишком много нагрузки.

Я использовал бы временное перенаправление для этого и удалю перенаправление при отключении трафика.

Но как обнаружить это, это я тоже хотел бы знать! Просто считая, что хиты за последние несколько секунд могут быть недостаточными?

Ответ 28

Убедитесь, что ваши страницы поддерживают заголовки Last-Modified и If-Modified-Since и/или ETag и If-None-Match. С их помощью вы можете полностью избежать многих вычислений и переводов.

Найти HTTP условный GET для получения дополнительной информации.

Ответ 29

nearfreespeech.net - полу облака, так сказать, и помогает тонну в подобных ситуациях. Как и многие другие, многоуровневое кэширование помогает. Потяните куски информации из memcached вместо базы данных, перед вами будет обратный прокси (или распределенный обратный прокси-сервер, например CDN, Panther Networks).

Ответ 30

Никто не упомянул о балансировке нагрузки... haproxy и т.д. Оптимизация, кеш и баланс нагрузки должны выдержать почти все. При этом я не уверен, что stackoverflow находится за балансировкой нагрузки;)