Пытаюсь понять как правильно кешировать веб-приложения(ASP.NET MVC на феб-ферме). Я немного погуглил на эту тему и вижу два варианта.
1. Кеширование непосредственно output'а .
2. Кеширование второго уровня для NHibernate.

Для кеша планирую использовать memcached.

Очень хотел бы услышать мнения коллег на этот счет…

Здравствуйте, FreddieM, Вы писали:

FM>Пытаюсь понять как правильно кешировать веб-приложения(ASP.NET MVC на феб-ферме). Я немного погуглил на эту тему и вижу два варианта.
FM>1. Кеширование непосредственно output'а .
FM>2. Кеширование второго уровня для NHibernate.

FM>Для кеша планирую использовать memcached.

FM>Очень хотел бы услышать мнения коллег на этот счет…

Мы делали кэширование бизнес-данных в inproc кэше ASP.NET + правильная обработка If-Modified-Since там где это возможно + реверс прокси(возможно распределённый для устранения single point of failure). Кэширование NHibernate'а в топку, ибо добавляет проблем больше, чем решает, плюс SQL Server сам неплохо умеет кэшировать возращаемые данные.
В общем всё зависит от масштаба вашего приложения

Здравствуйте, koandrew, Вы писали:

K>Здравствуйте, FreddieM, Вы писали:

FM>>Пытаюсь понять как правильно кешировать веб-приложения(ASP.NET MVC на феб-ферме). Я немного погуглил на эту тему и вижу два варианта.
FM>>1. Кеширование непосредственно output'а .
FM>>2. Кеширование второго уровня для NHibernate.

FM>>Для кеша планирую использовать memcached.

FM>>Очень хотел бы услышать мнения коллег на этот счет…

K>Мы делали кэширование бизнес-данных в inproc кэше ASP.NET + правильная обработка If-Modified-Since там где это возможно + реверс прокси(возможно распределённый для устранения single point of failure). Кэширование NHibernate'а в топку, ибо добавляет проблем больше, чем решает, плюс SQL Server сам неплохо умеет кэшировать возращаемые данные.
K>В общем всё зависит от масштаба вашего приложения

Я правильно понял, что html Вы не кешировали?
Какие проблемы могут быть с кешированием у NHibernate? Это я, как раз, сейчас и пытаюсь выяснить. Sql Server неплохо кеширует, но плохо горизонтально масштабируется (в отличии от веб-серверов или memcached), плюс на обращение к нему тоже время...

Здравствуйте, FreddieM, Вы писали:

FM>Я правильно понял, что html Вы не кешировали?
Мы использовали обработку If-Modified-Since для того, чтобы клиентское кэширование работало эффективно. Там этого оказалось достаточно.
FM>Какие проблемы могут быть с кешированием у NHibernate? Это я, как раз, сейчас и пытаюсь выяснить. Sql Server неплохо кеширует, но плохо горизонтально масштабируется (в отличии от веб-серверов или memcached), плюс на обращение к нему тоже время...
Проблемы типовые — когерентность кэша в пределах кластера. Вообще мы старались использовать сервер БД исключительно как хранилище данных — обрабатывали данные мы на веб-серверах, как раз по указанной вами причине — stateless веб сервера масштабируются гораздо эффективнее stateful серверов БД. Кластер из БД мы использовали в основном для устранения single point of failure, то есть для надёжности.

Здравствуйте, koandrew, Вы писали:
K>Мы использовали обработку If-Modified-Since для того, чтобы клиентское кэширование работало эффективно. Там этого оказалось достаточно.

А как это вы сделали? можно по-подробней?

Здравствуйте, Аноним, Вы писали:

А>А как это вы сделали? можно по-подробней?

Читаем спеку: http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html раздел 14.25
Вкратце — при выполнении запроса большинство современных браузеров отсылает вышеуказанный заголовок с датой, когда он получил эту же страницу в предыдущий раз (то есть когда страница была занесена в его кэш). Задача сервера — проверить, изменилась ли страница с тех пор или нет, если изменилась, то сервер посылает новую страницу, если же нет, то сервер отвечает 304 Not Modified и не рендерит страницу, браузер показывает пользователю страницу из своего кэша. В итоге при эффективной реализации сервер выполняет один запрос в БД и в случае отсутствия изменений с указанной даны не выполняет рендеринг страницы (то есть ему не нужно получать данные для рендеринга, привязывать их к гуе и собственно отрисовывать), также очевидно экономится полоса пропускания канала и, соответственно, сервер в состоянии выдерживать бОльшие нагрузки.

Здравствуйте, koandrew, Вы писали:

K>Читаем спеку: http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html раздел 14.25
K>Вкратце — при выполнении запроса большинство современных браузеров отсылает вышеуказанный заголовок с датой, когда он получил эту же страницу в предыдущий раз (то есть когда страница была занесена в его кэш). Задача сервера — проверить, изменилась ли страница с тех пор или нет, если изменилась, то сервер посылает новую страницу, если же нет, то сервер отвечает 304 Not Modified и не рендерит страницу, браузер показывает пользователю страницу из своего кэша. В итоге при эффективной реализации сервер выполняет один запрос в БД и в случае отсутствия изменений с указанной даны не выполняет рендеринг страницы (то есть ему не нужно получать данные для рендеринга, привязывать их к гуе и собственно отрисовывать), также очевидно экономится полоса пропускания канала и, соответственно, сервер в состоянии выдерживать бОльшие нагрузки.

Это я понял — я не понял как реализовать в ASP.NEt для страницы такое поведение

Здравствуйте, Аноним, Вы писали:

А>Это я понял — я не понял как реализовать в ASP.NEt для страницы такое поведение

В смысле? Что именно вы не поняли? Как отправить код 304? Или что-то ещё?

Здравствуйте, koandrew, Вы писали:
K>В смысле? Что именно вы не поняли? Как отправить код 304? Или что-то ещё?

я не пойму как у страницы определить когда она была модифицирована
и второй вопрос — этот код прийдется копировать во все страницы?

Правильно я понял? в Page_Load ищем заголовок If-Modified-Since и берем оттуда дату, сравниваем ее с датой модификации страницы (откуда ее взять у ASP.NET страницы?) если страница модифицирована — выдаем

Response.Cache.AddHeader('Last-Modified', дата модификации страницы)

и продолжаем, а если не модифицирована — выдаем

Response.StatusCode = 304;
Response.SuppressContent = true;
Response.End();

Правильно?

Здравствуйте, Аноним, Вы писали:

А>я не пойму как у страницы определить когда она была модифицирована
Страница модифицирована тогда, когда данные, которые она показывает, были модифицированы. Для выяснения этого во все отображаемые таблицы добавляют дату последнего изменения, после этого определение даты модификации страновится тривиальным.

А>и второй вопрос — этот код прийдется копировать во все страницы?
Не обязательно — можно просто реализовать это в базовом классе и отнаследовать все страницы от него.

А>Правильно я понял? в Page_Load ищем заголовок If-Modified-Since и берем оттуда дату, сравниваем ее с датой модификации страницы (откуда ее взять у ASP.NET страницы?) если страница модифицирована — выдаем

А>

А>Response.Cache.AddHeader('Last-Modified', дата модификации страницы) 
А>

А>и продолжаем, а если не модифицирована — выдаем

А>

А>Response.StatusCode = 304;
А>Response.SuppressContent = true;
А>Response.End();
А>

А>Правильно?
Примерно так.

Здравствуйте, Аноним, Вы писали:

А>Правильно я понял? в Page_Load ищем заголовок If-Modified-Since и берем оттуда дату, сравниваем ее с датой модификации страницы (откуда ее взять у ASP.NET страницы?) если страница модифицирована — выдаем

А>

А>Response.Cache.AddHeader('Last-Modified', дата модификации страницы) 
А>

А>и продолжаем, а если не модифицирована — выдаем

А>

А>Response.StatusCode = 304;
А>Response.SuppressContent = true;
А>Response.End();
А>

А>Правильно?

Единственное — я бы посоветовал делать эту проверку не в Page_Load, а как можно раньше в жизненном цикле страницы — чтобы избежать загрузки и инициализации контролов, которые всё равно будут не нужны в случае отсутствия изменений.

Здравствуйте, koandrew, Вы писали:

K>Проблемы типовые — когерентность кэша в пределах кластера.

Ну я думаю с этим проблем не будет, NHibernate умеет хранить кэш на memcached-серверах.

Здравствуйте, koandrew, Вы писали:

K>Читаем спеку: http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html раздел 14.25
K>Вкратце — при выполнении запроса большинство современных браузеров отсылает вышеуказанный заголовок с датой, когда он получил эту же страницу в предыдущий раз (то есть когда страница была занесена в его кэш). Задача сервера — проверить, изменилась ли страница с тех пор или нет, если изменилась, то сервер посылает новую страницу, если же нет, то сервер отвечает 304 Not Modified и не рендерит страницу, браузер показывает пользователю страницу из своего кэша. В итоге при эффективной реализации сервер выполняет один запрос в БД и в случае отсутствия изменений с указанной даны не выполняет рендеринг страницы (то есть ему не нужно получать данные для рендеринга, привязывать их к гуе и собственно отрисовывать), также очевидно экономится полоса пропускания канала и, соответственно, сервер в состоянии выдерживать бОльшие нагрузки.

Супер, большое спасибо!

Здравствуйте, FreddieM, Вы писали:

FM>Ну я думаю с этим проблем не будет, NHibernate умеет хранить кэш на memcached-серверах.
И что это меняет?

Здравствуйте, koandrew, Вы писали:

K>Здравствуйте, FreddieM, Вы писали:

FM>>Ну я думаю с этим проблем не будет, NHibernate умеет хранить кэш на memcached-серверах.
K>И что это меняет?

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

Здравствуйте, FreddieM, Вы писали:

FM>Если я правильно понимаю проблему, то она может возникнуть только когда есть несколько кэшей. Здесь же кэш один на отдельном memcached-сервере и, соответственно, такой проблемы быть не может.

...Но этим вы на ровном месте ввели single point of failure.