2010-07-30 3 views
1

Мы занимаемся оптимизацией производительности для многопользовательского веб-приложения. В настоящее время контекст данных LinqToSql создается в начале каждого веб-запроса. Контекст имеет всю жизнь для веб-запроса, и он вводится в конструктор любых объектов, которые ему нужны, используя Castle Windsor.Кэширование LINQ to SQL DataContext

Нам приходилось думать о кешировании контекста (и набора связанных с ним объектов) в кеше сеанса на несколько минут для оптимизации затрат на установку последующих веб-запросов. Это хорошая/плохая идея? Какие проблемы необходимо учитывать?

+0

Проанализировали ли вы каждый запрос, выполняемый через datacontext, чтобы обеспечить минимальное количество IO базы данных? Просматривали ли вы вызывающие стороны datacontext, чтобы убедиться, что повторные выборки для одних и тех же данных не происходят? –

+0

@David: настройка запросов, которые отображаются как горячие точки в профилировщике. наша реализация репозитория защищает от повторных попыток. – Rob

ответ

2

Плохая идея ИМО. Самой большой проблемой будет параллелизм. Благодаря объединению соединений затраты не так много, пока вы используете контекст данных как трубу для данных, а не для самого ведра данных.

Кэш данные; выбросить контекст данных.

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

У вас есть измеренные расходы на установку, чтобы вы знали, стоит ли это учитывать? Я действительно не верю, что это ваше узкое место.

+0

Мы измерили. Это не проблема создания dc, это данные. Наша первоначальная мысль была по вашим линиям, и мы бы определенно просто привязали ее, если бы это был сценарий разработки на новом уровне. Прежде чем мы реорганизуем регидратацию контекста, мы хотим понять, что на самом деле может пойти не так, если мы просто оставим постоянный ток в течение короткого промежутка времени. – Rob

+0

@Rob - вы не должны * нуждаться в * данных в вашем контексте данных. Это не означает, что * используется как хранилище данных (даже * с * идентификатором-менеджером). Лично я бы переместил данные * out * из контекста данных; используйте контекст данных, чтобы ** получить ** его, но кешировать его извне. –

+0

@Mark - согласился. В сценарии «нового плана» мы подходим к нему. Существующие репозитории записываются так, что они предполагают, что сущности находятся в наборе изменений, поэтому нам пришлось бы регидратировать контекст из кеша. Конечно, это невозможно, и, скорее всего, это то, что мы будем делать, но мы хотим понять все проблемы, прежде чем мы проведем там ограниченное время разработки. – Rob

Смежные вопросы