Что я должен сделать, чтобы масштабировать сайт с большим трафиком?

14

Какие передовые практики следует предпринять для веб-сайта, который необходимо «масштабировать» для управления пропускной способностью? Это особенно актуально сейчас, когда люди рассматривают облако, но могут упустить основные принципы.

Мне интересно услышать обо всем, что вы считаете лучшей практикой, от задач уровня разработки до инфраструктуры и управления.

goodguys_activate
источник
1
Посмотрите на: highscalability.com
Casebash
Может кто-нибудь, кто знает о Windows Server App Fabric и о кешировании, опубликовать что-нибудь здесь? Я не эксперт в этой области и хочу узнать больше.
goodguys_activate
Что вы хотите знать о AppFabric?
Хенрик
Есть несколько советов о том, как масштабировать веб-сайт, ознакомьтесь с ними. В том числе: Уровень сценария сервера переднего уровня Модель и уровень разработки БД Горизонтальное масштабирование сервера, Sharding Подробнее: olivetit.blogspot.com/2013/05/…

Ответы:

16

Дизайн для параллелизма

То есть, когда вы пишете код, планируйте создание нескольких потоков. Планируйте общее состояние (часто только БД). Планируйте несколько процессов. План физического распределения.

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

Fishtoaster
источник
13

Несколько вещей, которые вы могли бы рассмотреть:

  • Разделение сторон чтения и записи в вашем хранилище данных.
    • CQRS / Event Sourcing
    • ОКК
    • Передачи сообщений / Актёры
  • Как избежать общего процесса и состояния потока
    • Следовательно, избегая блокировки
    • Этого можно избежать с помощью системы типов, создавая неизменяемые классы, структуры и другие типы данных, то есть неизменяемые после построения. Специально для сложных абстрактных типов данных он работает на удивление хорошо (например, реализация jQuery)
  • Не блокирует потоки веб-сервера на IO. Если вы используете ASP.Net, используйте асинхронные страницы / действия с шаблоном APM / библиотекой параллельных задач (TPL)
  • Не сохранять нагрузки состояния в пользовательском словаре сессии
    • Это должно быть перемещено между потоками, когда миграции потоков происходят в IIS.
    • Имея интеллектуальную маршрутизацию, такую, что незащищенные / статические ресурсы не обслуживаются той же самой прикладной средой (например, ASP.Net), которая добавляет издержки. Посмотрите, например, на наличие разных веб-серверов.
  • Написание кода прохождения продолжения с асинхронным шаблоном рабочего процесса (например, bind (haskell) /callcc/Tasks.ContinueWith/F#'s async)
  • Используйте теорию очередей, чтобы рассчитать, где могут возникнуть ваши узкие места
  • Используйте push-, а не pull-based обновления для моделей чтения и других состояний приложения. Например, через RabbitMQ / nServiceBus
  • Используйте наименьший функционал «обработчик http»
  • Для статических файлов используйте электронные теги и политики истечения срока действия кэша, чтобы веб-инфраструктура работала должным образом (например, с прокси-сервером squid).
  • (Наймите меня, чтобы решить ваши проблемы масштабирования и получить учебные материалы на месте;))
Хенрик
источник
4

Ничего не делись архитектурой.

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

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

Jé Queue
источник
0

Распараллелить запросы по нескольким именам хостов

Частью стандарта HTTP является раздел, в котором говорится, что веб-клиенты будут запрашивать максимум 2 сеанса на хост DNS. Вот решение, при котором вы и ваш псевдоним www.domain.com получаете более высокий уровень параллелизма запросов, что ускоряет загрузку вашей страницы:

/programming/3653609/how-do-i-code-my-asp-net-page-to-parallelize-downloads-across-hostnames

По сути, это требует редактирования вашего ASP.NET HTTP Handler, чтобы чередовать целевые хосты, на которые вы отправляете клиентов, где каждый хост - это CNAME с «www».

goodguys_activate
источник
1
Этот ответ больше связан с производительностью на стороне клиента и никак не связан с масштабированием на стороне сервера.
Кен Лю
Я размышлял больше по линии среднего уровня, объединяя другие источники данных через HTTP. Azure Table, OData - это только некоторые примеры ... На ваш взгляд, все же, именно сервер сообщает браузеру (javascript), что делать.
goodguys_activate
0

Безопасный, быстрый, надежный DNS

Я нашел несколько веб-сайтов с высокой пропускной способностью, использующих DNS-сервер регистратора, который не имел SLA для обеспечения работоспособности или производительности. Кроме того, их серверы были расположены в Индии, и одна только латентность увеличивает вероятность того, что спуфер DNS может отравить кеш вашего клиента или промежуточный кеш провайдера. Это может привести к тому, что даже ваш трафик, защищенный SSL, будет перенаправлен без ведома.

Скорость DNS также влияет на начальное время загрузки вашего сервера до кэширования записей.

Я использую DynDNS или Neustar для большинства своих клиентов, поскольку у них довольно солидная DNS-инфраструктура (хотя это дорого, и у меня нет другой принадлежности к этим компаниям).

goodguys_activate
источник
2
Э-э ... DNS действительно серьезное узкое место для вас? Я думаю, это будет одна из последних вещей, которые нужно оптимизировать.
Fishtoaster
@Fishtoaster - только что отредактированная часть, выделенная жирным шрифтом. Изначально я являюсь системным администратором, и безопасность DNS играет большую роль в проверке SSL. Проблемы с подключением и производительностью DNS действительно возникают, такие как: проблемы маршрутизации BGP к SOA, проблемы с Anycasting (для CDN), проблемы с задержкой, отравление кэша и многое другое. Я написал инструмент проверки наилучшей практики DNS (проводной уровень), который скоро выложу в интернет. Не стесняйтесь опробовать его, так как он охватывает многие из упомянутых мной проблем с подключением. (или напишите мне по электронной почте, и я объясню больше)
goodguys_activate
2
Я не говорю, что нет проблем с производительностью, связанных с DNS, как те, которые вы перечислили. Мне просто кажется, что гораздо более основные проблемы (доступ к базе данных, кэширование страниц, сложность зацикливания кода, балансировка нагрузки на серверный процесс, выбор точки распространения оборудования и т. Д.) Возникнут и будут решены на несколько порядков при масштабировании до DNS связанные проблемы будут проблемой.
Fishtoaster
... Я полностью согласен, что есть более важные вещи, о которых нужно беспокоиться, как вы упомянули. Может быть, поэтому эта идея имеет нулевой рейтинг :) .. но опять же, я единственный, кто до сих пор ответил на этот вопрос.
goodguys_activate
1
Производительность DNS, безусловно, может стать огромным узким местом - разница между хорошим и плохим не может быть много мс, но поскольку DNS получает удар при каждом вызове (или почти при каждом вызове), он может накапливаться очень быстро. Особенно, когда вы попадаете в современные трюки CDN.
Уайетт Барнетт
0

Я думаю, что ключ будет прост:

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

Тогда вы можете проверить и найти проблемы.

Смотрите здесь: http://blog.servint.net/2013/08/27/going-big-how-to-scale-a-website-part-1-infrastructure-that-scales/

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

msj121
источник