Ресурсы для обучения, как справиться с интенсивным трафиком на сайте asp.net mvc? - PullRequest
Новая
       4

Ресурсы для обучения, как справиться с интенсивным трафиком на сайте asp.net mvc?

6 голосов
/ 27 декабря 2010

сколько трафика интенсивного трафика?Какие ресурсы лучше всего узнать о разработке веб-сайтов с большим трафиком? .. Каковы подходы?

Ответы [ 3 ]

9 голосов
/ 28 декабря 2010

Существует множество принципов, применимых к любому веб-сайту, независимо от базового стека:

  • использует средства HTTP-кэширования.Для одного есть кеш пользовательского агента.Во-вторых, вся веб-магистраль полна прокси-серверов, которые могут кэшировать ваши запросы, поэтому используйте это в полной мере.Запрос, который даже приземлится на ваш сервер, добавит 0 к вашей нагрузке, вы не можете оптимизировать лучше, чем это:)
  • , следуя вышеприведенному пункту, используйте CDN (Content Delivery Network, например, CloudFront)) для вашего статического контента.CSS, JPG, JS, статический HTML и многие другие страницы могут обслуживаться из CDN, тем самым сохраняя веб-сервер от HTTP-запроса.
  • Второе следствие первого пункта: добавьте подсказки кеширования истечения для вашего динамического контента.Даже короткое время жизни кеша, например, 10 секунд, сэкономит много обращений, которые вместо этого будут обслуживаться всеми прокси, расположенными между клиентом и сервером.
  • Минимизируйте количество HTTP-запросов.Кажется базовым, но, вероятно, это лучшая пропущенная оптимизация.На самом деле, лучшие практики Yahoo ставят это как наивысшую оптимизацию, см. Лучшие практики для ускорения вашего сайта .Вот их список практик:
    • Минимизация HTTP-запросов
    • Использование сети доставки контента
    • Добавление заголовка Expires или Cache-Control
    • Gzip Components
    • ... (на самом деле список довольно длинный, просто прочитайте ссылку выше)

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

  • уменьшит количество вызовов БД на страницу .Наилучшая возможная оптимизация, очевидно, состоит в том, чтобы вообще не отправлять запрос в БД.Некоторые говорят, что 4 операции чтения и 1 записи на страницу - это наибольшая нагрузка для сервера с высокой нагрузкой, другие говорят, что один вызов БД на страницу, а другие говорят, что 10 вызовов на страницу - это нормально.Дело в том, что меньше всегда лучше, чем больше, и записи значительно дороже, чем чтение.Просмотрите ваш дизайн пользовательского интерфейса, возможно, количество посещений в углу страницы, которое никто не видит, не обязательно должно быть , точным ...
  • Убедитесь, что каждый запрос БДвы отправляете на SQL сервер оптимизированный .Посмотрите на каждый план запроса, убедитесь, что у вас есть правильные индексы покрытия , убедитесь, что вы не выполняете сканирование таблицы, просмотрите стратегию дизайна кластеризованных индексов , просмотрите всеваша нагрузка ввода-вывода, структура хранилища и т. д. Действительно, вы не можете использовать ее как можно быстрее, вы должны проанализировать и оптимизировать эту базу данных, она будет вашей точкой удара.
  • устранить разногласия .Не заставляйте читателей ждать писателей.Для вашего стека SNAPSHOT ISOLATION является обязательным.
  • кеш результатов .И обычно это печенье крошится.Создание хорошего кэша на самом деле довольно сложно.Я бы порекомендовал вам посмотреть суть Facebook SOCC: Создание Facebook: производительность в массовом масштабе .Где-то на слайде 47 они показывают, как выглядит типичный внутренний API Facebook:

. 

cache_get (
  $ids,
  'cache_function',
  $cache_params,
  'db_function',
  $db_params);

Все запрашивается из кэша, и если нетнайдено, запрошено у их MySQL бэкэнда.Вы, вероятно, не начнете с 60000 серверов подумал :)

В стеке SQL Server лучшая стратегия кэширования - это стратегия, основанная на Уведомления о запросах .Вы можете почти смешать его с LINQ ...

4 голосов
/ 27 декабря 2010

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

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

Принципы одинаковы, независимо от того, используете ли вы MVC или нет, когда речь идет об оптимизации скорости.

  1. Наличие развязанной архитектуры облегчает масштабирование путем добавления больше серверов и т. д.
  2. Использовать репозиторий шаблон для поиска данных (делает проще добавить кеш)
  3. Данные кеша что дорого запрашивать
  4. Данные в быть написано может быть написано через кеш, чтобы у клиента не было ждать актуальную базу данных совершить

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

0 голосов
/ 28 декабря 2010

MSDN имеет некоторые ресурсы по этому вопросу. Эта конкретная статья устарела, но это только начало.

Я бы также предложил не ограничиваться чтением о стеке MVC: многие принципы являются кроссплатформенными.

...