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

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

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

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

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

Основы:

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

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

1. На самом деле знаете свой SQL и тратите время на анализ медленных запросов. Для большинства загрузок страниц не требуется более секунды прямых запросов.
2. Определите, где ваша нагрузка действительно. Если это медиа-сайт, подумайте о размещении контента в другом месте (например, Akamai или какой-либо другой сервис). Если это сайт с тяжелой базой данных, подумайте о репликации.
3. Знайте, какая репликация будет работать для вас. Если у вас есть сайт с высокой прочностью, стандартная репликация master / slave MySQL должна быть в порядке. Если у вас много записей, вам понадобится какая-то настройка с несколькими мастерами, например, кластер MySQL (или расследовать репликацию «каскадирование» или «водопад»).
4. Если вы можете, не вызывайте PHP – т.е. имеете кешированную статическую (HTML) копию страницы (это то, что делает большинство плагинов для кэширования WordPress). Apache гораздо быстрее обслуживает статические файлы, чем даже самый простой скрипт PHP hello world.

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

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

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

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

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

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

Я переписываю все 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> 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

и т.п.

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

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

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

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

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

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

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

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

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

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

Любое кэширование, которое вы используете, поможет вам получить пуленепробиваемый (или slashdot / digg-proof) ваш сайт 🙂

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

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

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

Данные кэша.

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

Авто-перенаправление на Coral CDN, если запрос не из кораллового cdn.

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

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

и т.п.

.htaccess:

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

Одно слово: Knipex

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

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

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

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

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

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