При масштабировании asp.веб-сайт net-mvc, на чем стоит сосредоточиться с точки зрения приоритета?

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

в соответствии с вопросом у меня есть идеальный хороший рабочий asp.сайт net-mvc с бэкэндом SQL server и использованием кэша NHibernate и syscache 2-го уровня, и у меня есть запрос на увеличение базы пользователей с 1000 до 7000, и я пытаюсь понять, на чем я должен сосредоточить свою энергию развития с точки зрения вещей, которые сейчас прекрасно работают, но будут вызывать проблемы в масштабе. Я много читал, и до сих пор вещи, которые, кажется, представляют интерес с точки зрения кодирования;

  1. Контроллеры Asyncronous
  2. кэширование вывода (не очень релевантно для меня, поскольку большинство моих страниц являются динамическими и пользовательскими правами специфический
  3. другое?

мой SQL server сегодня составляет 4 ГБ, и с точки зрения данных я ожидал бы, что некоторые из таблиц будут линейно расти в размере (например, таблица person, которая будет расти с 1000 строк до 7000 строк) с этим увеличением пользователей, но большинство других таблиц (справочные данные и т. д.) должны иметь только предельный рост (например, таблица location может удвоиться)

9
asp.net-mvc iis scalability

3 ответов

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

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

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

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

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

  1. кэш данных. Это связано с соображениями для устаревших данных, а также стратегий обновления данных.
  2. распределить данные (sharding), когда у вас много серверов баз данных, каждая из которых содержит только подмножество данных. Веб-сервер выдает параллельные запросы серверам, каждый сервер запрашивает подмножество (которое мало и так быстро) и возвращает обратно, затем веб-сервер собирает все данные куски для пользователя. Большинство баз данных NoSQL сегодня поставляются со встроенным шардингом и распределенными запросами.
  3. редизайн пользовательского потока для обработки запроса как команды. например, возьмите запрос пользователя и позвольте пользователю продолжить просмотр. Соберите все необходимые данные в фоновом режиме (обычно используя ту же технику, что и для команд) и сообщите пользователю, когда это будет сделано. Когда пользователь переходит на страницу результатов, извлеките предварительно сгенерированные данные (обычно из локальной базы данных, которая быстрее поиск.)
  4. ключевые слова async и await в C#. Не только для контроллеров, но и для других методов, которые вызывают ваши контроллеры, если они/вы заблокируете поток во время ожидания завершения. Использование async и await освободит потоки запросов, чтобы другие параллельные запросы могли использовать эти потоки. Помните, что это не сокращает фактический запрос пользователя, а только освобождает ресурсы веб-сервера для оптимального использовать.
4

резервное копирование

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

хранение данных в автономном режиме

Data нуждается в доме. Создание надежной системы хранения данных очень важна. Это когда вы идете в автономном режиме по какой-то причине.

структурное тестирование

стресс тестирование поможет вам узнать, что исправить. Заполните базу данных с 10 000 случайных элементов и проверить все функции, которые вы можете. Попробуйте найти конкретные идентификационные номера.

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

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

1

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

На Уровне Приложения

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

кроме того, убедитесь, что все ваши таблицы стилей и активы javascript скомпилированы в мини - отдельные файлы в рабочей среде. Это уменьшит нагрузку на ваш веб-сервер.

Бэкэнд Уровень

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

тестирование

в тестовой среде (!!!) используйте инструмент подделки записей базы данных, например Факер (это Рубин, но вы получаете идея.) Протестируйте обычные транзакции с гораздо большим размером таблицы, чем обычно, и узкие места производительности начнут проявляться более заметно.

1