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

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

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

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

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

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

• Защитите свой сервер от Slashdot с помощью FreeCache - Боинг Боинг
• Блог "Простые мысли" теперь называется Slashdot. Доказательство

и т.п.

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

На самом деле, здесь не так уж и плохо.

Кэшировать данные.

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

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

Основы:

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

Настоящие ответы:

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

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

.htaccess:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

In this paper, we consider the question of scaling through the eyes of a character we call the garage innovator. The garage innovator is creative, technically savvy, and ambitious. She has a great idea for the Next Big Thing on the web and implements it using some spare servers sitting out in the garage. The service is up and running, draws new visitors from time to time, and makes some meager income from advertising and subscriptions. Someday, perhaps, her site will hit the jackpot. Maybe it will reach the front page of Slashdot or Digg; maybe Valleywag or the New York Times will mention it.

Our innovator may get only one shot at widespread publicity. If and when that happens, tens of thousands of people will visit her site. Since her idea is so novel, many will become revenue-generating customers and refer friends. But a flash crowd is notoriously fickle; the outcome won't be nearly as idyllic if the site crashes under its load. Many people won't bother to return if the site doesn't work the first time. Still, it is hard to justify paying tens of thousands of dollars for resources just in case the site experiences a sudden load spike. Flash crowds are both the garage innovator's bane and her goal.

One way out of this conundrum has been enabled by contemporary utility computing.

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

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

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

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

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

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

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