Стратегии кэширования БД WCF ​​/ Silverlight / SQL

Question

Хорошо, у меня есть довольно сложное приложение silverlight, которое получает свои данные от службы WCF (слой размещенного сервиса asp.net), которое, в свою очередь, вызывает уровень данных, который вызывает хранимые процедуры в БД SQL 2005 для извлечения необходимых данных , Таким образом, поездка туда и обратно выглядит так:

Приложение Silverlight -> Служба WCF -> Уровень данных -> БД -> Уровень данных -> Служба WCF преобразует объект данных в соответствующий DTO (объект передачи данных) или его список <> -> Приложение Silverlight

Большая часть данных является высокореляционной (поэтому она должна существовать в БД), но она будет меняться нечасто. Кажется, у меня есть несколько вариантов расположения, чтобы кэшировать эти «полупостоянные» данные:

1. Я могу кешировать его в слое данных. Мой уровень данных уже настроен для использования класса SQLDependency и кэширования результатов от вызова хранимой процедуры. Я думаю, что это или может быть кеш уровня приложения.
2. Я могу кэшировать результирующий DTO в кеше уровня приложения (или уровне сеанса в зависимости от вызова) внутри самой службы WCF. 2 (а) Я мог бы даже сделать этот шаг дальше, сериализовав XML для результирующих DTO в файл на стороне службы WCF, чтобы я мог (а) проверить кэш памяти, затем (б) проверить кэш файлов и (c) ударить слой данных
3. Я мог бы сделать что-то похожее на 2 (а) с изолированным хранилищем на стороне клиента в приложении SL. Я мог бы сериализовать данные в локальное изолированное хранилище с помощью хэша (или моддата или чего-то еще), а затем просто позвонить, чтобы проверить это.

Еще одна вещь, которую нужно добавить: я размещаю эту службу WCF в IIS7 с включенным динамическим сжатием, чтобы (часто очень большой и легко сжимаемый) XML-ответ получал gzip-ed. В идеале, казалось бы, я хотел бы, чтобы IIS кешировал этот gzip-ed результат, чтобы избежать всей дополнительной обработки. Я думаю, что это может сделать это уже, но я не уверен.

Я почти уверен, что окончательный ответ на этот вопрос - это какая-то разновидность "это зависит", но я хотел бы услышать, как другие приближаются к этому. Хороший тактический рецепт Do X, Test Performance с инструментом Y, было бы здорово иметь do Z.

Несколько ссылок (я добавлю к этому, когда буду исследовать это):

Подход кэширования WCF

Answer 1

Мой подход был бы таким:

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

Также помните, что кэширование не должно быть первым, что нужно сделать для повышения производительности. Вы также должны посмотреть на другие приросты производительности. Хранимые процедуры медленные? Много ли накладных расходов в сообщениях WCF? Есть ли какая-то неэффективная обработка в сервисе? Нужно ли мне все эти данные в одном сообщении?

НТН, Jonathan

Answer 2

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

Dino Sposito опубликовал интересную статью о локальном хранении и кэшировании в журнале MSDN Magazine, где вы также можете найти подход для перехвата сборок (представьте себе, просто загружая необходимый минимальный пакет и просто загружая остальные сборки в фоновом режиме, производительность ракета, больше сложности на ваш код:)).

Как вы сказали, важно поставить баланс и решить.

НТН Braulio

Answer 3

Если вы используете RIA Services, тогда простой подход состоит в том, чтобы иметь два отдельных определения edmx. Один для кэшированных объектов, один для транзакционных.

Один контекст домена может ссылаться на объекты в другом доменном контексте через AddReference см. .

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

В зависимости от размера кэша вы можете также рассмотреть возможность сериализации этих значений в локальное хранилище.

Answer 4

Мы только недавно внедрили # 3, кэширование на стороне клиента с использованием изолированного хранилища.

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

Это исключило множество вызовов WCF и передачу данных, время загрузки страниц SL сократилось, а приложение в целом стало более масштабируемым из-за уменьшения сетевого трафика и доступа к базе данных.

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

Andrew

Answer 5

Доступно ли кэширование System.Web для WCF, даже если он не работает в режиме, совместимом с ASP.NET? Наверное, лучше не зависеть от этого и написать свое.

С другой стороны, загляните в проект Microsoft Velocity, который, похоже, создаст очень интересную технологию кэширования, не зависящую от ASP.NET.

Answer 6

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

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