Как я могу кэшировать личные данные в веб-ферме для ASP MVC

Question

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

Забегая вперед в этом сценарии, я знаю, что база данных является узким местом в большинстве веб-приложений.Мы используем MSSQL 2008RS, у нас будут выделенные серверы с несколькими клиентскими базами данных, у каждого клиента есть собственная база данных, поэтому, если один сервер начинает становиться узким местом, мы можем масштабировать по вертикали или перенести некоторые базы данных на новый сервер и начать его заполнять.

Для доступа к базам данных мы используем в основном LINQ 2 SQL и в настоящее время перефакторируем часть нашего кода, чтобы использовать механизмы IQueryable для ленивой загрузки содержимого.но каждая страница содержит довольно много контента из разных частей базы данных.

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

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

Если так, то с чего мне начать?Я кратко рассмотрел структуру приложения, но она выглядит так, как будто она предназначена только для Azure?

Ресурсы:

Как кэшировать данные в приложении MVC

http://stephenwalther.com/blog/archive/2008/08/28/asp-net-mvc-tip-39-use-the-velocity-distributed-cache.aspx

http://stephenwalther.com/blog/archive/2008/08/29/asp-net-mvc-tip-40-don-t-cache-pages-that-require-authentication.aspx

Answer 1

1. Ленивая загрузка - убийца производительности. Лучше загружать весь граф объектов одним объединением, чем лениво загружать другие свойства. Особенно это касается списка объектов. Если вы сделаете итерацию, то в конечном итоге загрузите каждый элемент списка. Кроме того, каждый вызов в БД имеет накладные расходы. Меньше звонков = лучшая производительность.

2. SO был топ-1000, прежде чем ему понадобилось два сервера баз данных. Я думаю, ты будешь в порядке.

3. Если ваша модель доходов гласит: «У каждого клиента будет своя собственная база данных», то ваши проблемы масштабирования должны быть действительно легко решаемыми. Похоже, у вас уже есть план по увеличению количества серверов по мере увеличения клиентской базы. В чем проблема?

4. Кэширование на веб-уровне обычно является первым исправлением масштабирования, о котором вам нужно беспокоиться. Вам, вероятно, не нужно делать новый вызов БД с каждым запросом страницы.

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

Answer 2

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

AppFabric определенно не просто лазурь; в конце концов, я не смог установить его (и использовать) локально :) но на самом деле между AppFabroc, redis и memcached мало (последнему, конечно, не хватает устойчивости).

Но я думаю, вам изначально стоит взглянуть на использование встроенного кэширования asp.net; как кэширование данных через HttpContext.Cache, так и кэширование целых ответов (или, в MVC 3, частичные). Очевидно, вы должны иметь общее представление о том, какие данные интенсивно используются многими запросами, и безопасно ли их повторно использовать: кэшируйте это!

Просто убедитесь, что вы рассматриваете все кэшированные FAA как неизменяемые (если вам нужно обновить кэш, повторно добавьте измененное значение; не изменяйте существующие объекты) - причина: он не будет работать так же, если вы запустите необходимость использования распределенного кэширования, так как при этом используется сериализация, и любые сделанные вами изменения не будут видны при следующем запросе.