gandjustas9 фев 2013 в 20:26

Кеширование в ASP.NET MVC

6 мин

48K

.NET * Веб-разработка *

+13

Комментарии 26

lair 9 фев 2013 в 21:03

Чтобы такой ситуации, как описано выше, не происходило надо разделить запросы и собирать части страницы на клиенте

А что, способов это сделать на сервере нет? Partial views и RenderAction отменили?

(я уже не говорю про многоуровневое кэширование данных)

lair 9 фев 2013 в 21:07

Поправка: partial views не кэшируются, конечно, а вот child actions — легко.

gandjustas 9 фев 2013 в 21:09

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

lair 9 фев 2013 в 21:17

Такие вещи (пусть они и кажутся самоочевидными), надо мерять, а не говорить «надо делать вот так».

gandjustas 9 фев 2013 в 21:43

Если страница и её части 90% времени отдаются из кеша клиента\прокси сервера, то это будет все равно быстрее, чем сколь угодно заоптимизированная страница, отдаваемая серверным кодом. Потому что результат один и тот же (в смысле ответа сервера), а время на передачу данных от сервера клиенту гораздо меньше.

lair 10 фев 2013 в 08:39

Если это одна страница, то вы, возможно, правы. А вот если страница + ajax-запросы — то уже не обязательно.

Ну и да, еще нужно доказать про 90%.

tym32167 9 фев 2013 в 21:19

Интересно, а если на странице будет много некешируемой информации (логин юзера, корзина, последние статьи/форумы/комментарии), и для каждого такого контрола делать ajax запрос на сервер, это будет быстрее, чем просто за раз все собрать на сервере (вместе с кешируемым контентом) и вернуть одной страницей? Думаю, тут надо в каждом случае делать тесты и выбирать один из вариантов.

gandjustas 9 фев 2013 в 21:46

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

Но в любом случае все что связано с быстродействием надо измерять.

RouR 12 фев 2013 в 06:55

Если уж говорить про ASP.NET MVC и write-through кеш, то есть вот такая штука из коробки:

[OutputCache(Duration = 120, Location = OutputCacheLocation.Server, SqlDependency = "Site:Folders;Site:FoldersTree;")]

lair 12 фев 2013 в 07:10

Вот скажите, у вас эти SqlDependency «из коробки» взлетели?

RouR 12 фев 2013 в 07:28

Да, сама SqlDependency взлетела. В Application_Start() надо сконфигурировать, плюс ещё в Web.config, и насколько помню — при деплое в БД будет создана таблица AspNet_SqlCacheTablesForChangeNotification и триггеры на таблицы.

String connStr = System.Configuration.ConfigurationManager.ConnectionStrings["SQLConnectionMain"].ConnectionString;
System.Web.Caching.SqlCacheDependencyAdmin.EnableNotifications (connStr);
System.Web.Caching.SqlCacheDependencyAdmin.EnableTableForNotifications(connStr, "Folders");
System.Web.Caching.SqlCacheDependencyAdmin.EnableTableForNotifications(connStr, "FoldersTree");
System.Web.Caching.SqlCacheDependencyAdmin.EnableTableForNotifications(connStr, "FoldersPropertys");

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

lair 12 фев 2013 в 07:30

А, это, значит, уже новые SqlDependencies, потому что старые сидели на Query Notifications, и это был тихий ужас. Надо будет попробовать.

gandjustas 12 фев 2013 в 07:36

Это те же самые SqlDependencies, только они в namespace System.Web.Caching и изначально заточены под кеширование в ASP.NET. По сути они все вызывают классы SqlDependency в SqlClient.

lair 12 фев 2013 в 07:37

Т.е., тоже работают через Query Notifications, а не через поллинг таблиц? Тогда не интересно.

gandjustas 12 фев 2013 в 07:40

Это настраивается. msdn.microsoft.com/ru-ru/library/system.web.caching.sqlcachedependency.aspx

RouR 12 фев 2013 в 07:45

Думаю будет полезно дополнить статью примером с SqlDependency, поллингом таблиц и VaryByCustom=«user»

gandjustas 12 фев 2013 в 07:51

Думаю другую надо написать…

lair 12 фев 2013 в 08:17

Я вот не нашел там ничего про настройку поллинга.

gandjustas 12 фев 2013 в 08:26

Снизу страницы

lair 12 фев 2013 в 08:32

Конкретную цитату можете дать? Которая бы привела к тому, что на SQL 2008R2 использовались бы не Query Notifications, а поллинг таблиц.

gandjustas 12 фев 2013 в 08:43

82.157.70.109/mirrorbooks/asp.net/8877final/LiB0082.html тут вроде детально написано про polling.

lair 12 фев 2013 в 08:55

Вы на дату книжки смотрели? У меня вот есть болезненное ощущение, что начиная с 2005 SQL автоматически включаются Query Notifications вместо триггеров.

gandjustas 12 фев 2013 в 09:15

Я сам это пробовал последний раз в 2006 году. Вот относительно свежая статья: www.dotnetfunda.com/articles/article1382-how-to-implement-sql-caching-in-aspnet-poll-based-sql-cache-dependency.aspx
Думаю обратная совместимость в этом месте есть.

gandjustas 12 фев 2013 в 09:19

Поковырялся ILSpy, есть обратная совместимость. Если не указан polling, то пытается прицепиться к оповещениям, если Polling указан, то запускает таймер.

lair 12 фев 2013 в 10:15

Ок, спасибо. Будем смотреть.

gandjustas 12 фев 2013 в 07:34

Потому что кеш на сервере общий, надо прикручивать VaryByCustom=«user» и переопределять GetVaryByCustomString в HttpApplication.

Подробнее тут: msdn.microsoft.com/ru-ru/library/5ecf4420(v=vs.90).aspx

Зарегистрируйтесь на Хабре, чтобы оставить комментарий