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

Question

Причина, по которой я спрашиваю, заключается в том, что произошло переполнение стека С Косой чертой, и Подкрашенный.

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

Answer 1

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

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

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

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

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

Answer 2

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

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

Более сложные решения зависят от способности к быстрому масштабированию.Это, во-первых, проблема с программным обеспечением (можете ли вы подключиться к базе данных на другом сервере, можете ли вы выполнить балансировку нагрузки).Во-вторых, ваше хостинг-решение должно поддерживать быстрое расширение.На ум приходит Amazon EC2 или, может быть, slicehost.С помощью обеих служб вы можете легко запускать новые экземпляры ("Давайте переместим базу данных на другой сервер") и расширять свои экземпляры ("Давайте обновим сервер базы данных до 4 ГБ оперативной памяти").

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

Answer 3

Разработчику приложений необходимо подумать о расширении (более крупные машины с большим количеством ядер и более высокой производительностью) и / или масштабировании (распределение рабочей нагрузки между несколькими системами).ИТ-специалисту нужно решить, как наилучшим образом это поддержать.Сеть - это то, на что вы обращаете внимание в первую очередь, потому что, очевидно, все зависит от нее.Начиная с границы, это обычно означает, что сетевые балансировщики нагрузки и резервные маршрутизаторы обслуживаются несколькими провайдерами.Вы также можете ознакомиться с сервисами географического кэширования и приложениями, такими как cachefly.

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

Answer 4

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

Вы можете передавать большие файлы на аутсорсинг внешним сервисам, таким как Amazon S3, экономя пропускную способность вашего сервера.

И если вы в состоянии потратить немного (трехзначную сумму в месяц) долларов, вы также можете воспользоваться Сетью доставки контента.Благодаря этому вы автоматически обеспечиваете масштабирование, высокую доступность и низкие задержки для ваших пользователей.Конечно, ваши страницы должны быть кэшируемыми, поэтому сеансовые ключи и персонализированные страницы недопустимы.При тщательном проектировании и с учетом CDN вы можете, по крайней мере, кэшировать НЕКОТОРЫЙ контент, такой как фотографии, видео и статические материалы.

Answer 5

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

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

Даже небольшой барьер для входа, например требование ввести имя пользователя или адрес электронной почты, даже если проверка не проводилась, значительно снизит объем вандализма.