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

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

(я уже не говорю про многоуровневое кэширование данных)
Поправка: partial views не кэшируются, конечно, а вот child actions — легко.
Кеширование HTTP использует в качестве ключа url. Если серверу придется каждый раз отдавать страницу, даже собираемую из кеша на сервере, то это будет в разы медленнее, чем клиент просто будет брать страницу из локального кеша или из кеша прокси-сервера.
Такие вещи (пусть они и кажутся самоочевидными), надо мерять, а не говорить «надо делать вот так».
Если страница и её части 90% времени отдаются из кеша клиента\прокси сервера, то это будет все равно быстрее, чем сколь угодно заоптимизированная страница, отдаваемая серверным кодом. Потому что результат один и тот же (в смысле ответа сервера), а время на передачу данных от сервера клиенту гораздо меньше.
Если это одна страница, то вы, возможно, правы. А вот если страница + ajax-запросы — то уже не обязательно.

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

Но в любом случае все что связано с быстродействием надо измерять.
Если уж говорить про ASP.NET MVC и write-through кеш, то есть вот такая штука из коробки:
[OutputCache(Duration = 120, Location = OutputCacheLocation.Server, SqlDependency = "Site:Folders;Site:FoldersTree;")]
Да, сама 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");

При обновлении таблиц — кеш обновлялся.
Во время тестов всплыл баг: пользователь мог получить чужой кеш.
А, это, значит, уже новые SqlDependencies, потому что старые сидели на Query Notifications, и это был тихий ужас. Надо будет попробовать.
Это те же самые SqlDependencies, только они в namespace System.Web.Caching и изначально заточены под кеширование в ASP.NET. По сути они все вызывают классы SqlDependency в SqlClient.
Т.е., тоже работают через Query Notifications, а не через поллинг таблиц? Тогда не интересно.
Думаю будет полезно дополнить статью примером с SqlDependency, поллингом таблиц и VaryByCustom=«user»
Конкретную цитату можете дать? Которая бы привела к тому, что на SQL 2008R2 использовались бы не Query Notifications, а поллинг таблиц.
Вы на дату книжки смотрели? У меня вот есть болезненное ощущение, что начиная с 2005 SQL автоматически включаются Query Notifications вместо триггеров.
Поковырялся ILSpy, есть обратная совместимость. Если не указан polling, то пытается прицепиться к оповещениям, если Polling указан, то запускает таймер.
Only those users with full accounts are able to leave comments. Log in, please.