Технология Клиент-Сервер 2002'3

Home

Поиск

Издания

Контакты

k-press.ru

Продолжается подписка на наши издания! Вы не забыли подписаться?

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

Игорь Шапошников

Кэширование: как и зачем

Помните шутливую расшифровку аббревиатуры WWW? Это World Wide Wait. Увы, далеко не все имеют хороший канал, и пользователи достаточно часто раздражаются, ожидая окончания загрузки web-страниц. К сожалению, разработчики не в силах улучшить пропускные возможности каналов пользователей или кардинально уменьшить размеры Web-страниц. Однако некоторая возможность сократить время загрузки Web-страниц все же есть. Я, конечно, говорю о кэшировании.

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

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

Управление кэшированием на стороне клиента

В ASP.NET в состав объекта HttpResponse был введен еще один дополнительный объект с наименованием Cache. Он реализуется при помощи класса HttpCachePolicy. И этот объект предоставляет разработчику поистине беспрецедентный объем возможностей. Рассмотрим методы и свойства данного класса.

AppendCacheExtension. Метод устанавливает значение для заголовка HTTP Cache-Control. В качестве параметра методу передается значение типа String, которое и будет содержимым данного заголовка HTTP. Необходимо упомянуть, что полностью все возможности, связанные с данным заголовком HTTP, реализованы только в браузере Internet Explorer последних версий. Иные браузеры просто проигнорируют данный заголовок, если в нем будут встречаться неизвестные параметры. Полностью возможные параметры для этого заголовка HTTP описаны в документе RFC 2616. Однако здесь мы приведем два наиболее часто используемых параметра. Один из них носит наименование "pre-check". Значением данного параметра является целое число, указывающее продолжительность временного промежутка в секундах. Данный параметр указывает время, в течение которого разработчик или приложение не планируют изменять web-страницу. Но при этом нельзя сказать точно, что она не будет изменена. Это просто планирование. Второй параметр обычно используется в паре с первым, и носит наименование "post-check". Его значением также является целое число, указывающее продолжительность временного промежутка в секундах. В течение этого промежутка времени браузер по запросу пользователя отображает web-страницу из локального кэша, но при этом в фоновом режиме проверяет исходную версию web-страницы, находящуюся на WWW-сервере, таким образом уменьшая риск предоставления неадекватной информации в будущем.
SetCacheability. Метод устанавливает правила кэширования web-страницы в сети. То есть, область действия этого метода распространяется и на прокси-серверы. В качестве параметра данному методу передается значение типа HttpCacheability. Данный тип является перечислимым, и в его состав входят следующие константы:
- NoCache. Значение указывает, что данная web-страница вообще не подлежит кэшированию, и браузер всегда должен запрашивать web-страницу с сервера.
- Private. Значение используется по умолчанию. Указывает, что web-страница может кэшироваться браузером удаленного пользователя, но прокси-серверы не должны хранить ее копию в своем кэше.
- Public. Значение указывает, что web-страница может кэшироваться как браузером, так и прокси-серверами.
- Server. Указывает, что кэшировать web-страницу будет сам WWW-сервер. С точки зрения конечного получателя web-страницы, нет никакой разницы между вариантами NoCache и Server, так как и в том и в другом случае ни браузер, ни прокси-сервер не имеют права кэшировать web-страницу, однако с точки зрения разработчика разница все-таки достаточно существенная. В конце концов, именно разработчику придется думать, как осуществлять кэширование web-страниц на своем сервере.
SetExpires. Метод позволяет устанавливать точную дату и время, до наступления которых web-страница не будет изменена, и браузер может использовать ее локальную версию, сохраненную в собственном кэше или кэше прокси-сервера. В качестве параметра методу передается значение типа DateTime.
SetLastModified. Метод позволяет указывать для web-страницы дату и время ее последнего изменения. При этом, по сути, устанавливается значение заголовка HTTP с наименованием Last-Modified. В качестве параметра методу передается значение типа DateTime.
SetLastModifiedFromFileDependencies. Данный метод, подобно предыдущему, устанавливает значение заголовка HTTP с наименованием Last-Modified. Но при этом разработчик не должен передавать устанавливаемое значение в качестве параметра. Метод сам получает его на основе атрибутов файлов.
SetNoServerCaching. Метод запрещает серверу производить кэширование искомой web-страницы в своем кэше. То есть, при выполнении данного метода все запросы к web-страницы должны выполняться в полном объеме, а заранее сохраненная в кэше WWW-сервера копия страницы пользователю предоставляться не будет.

Итак, в этом разделе мы рассмотрели использование объекта Cache, входящего в состав объекта HttpResponse. Впрочем, все вышесказанное относится лишь к кэшированию страниц на стороне клиента. Чтобы использовать этот механизм, необходимо быть уверенным, что в течение времени хранения web-страницы в кэше, она не будет изменена. То есть, требуется некоторая статичность ресурса. А если разработчик создает сайт с использованием технологии ASP.NET, трудно предположить, что в его состав будет входить так уж много статичных страниц. Однако это еще не повод отказываться от кэширования. Просто надо использовать другую его ипостась — кэширование на стороне сервера.

Кэширование страниц на сервере

Web-страницы могут кэшироваться и на сервере. Это необходимо для того, чтобы снизить нагрузку на него и уменьшить время отклика сервера на запрос пользователя. Скажем, пользователи часто запрашивают некий набор данных из БД. А сама БД меняется достаточно редко. Следовательно, нет нужды постоянно генерировать свежую версию страницы, отображающей этот набор данных, ее можно просто хранить в кэше сервера. Это, несомненно, можно считать экономией времени, которая будет особенно хорошо проявляться в моменты пиковой загрузки сервера. Однако, здесь тоже есть свои подводные камни...

<...>

Заключение

Итак, теперь мы знаем, при помощи каких методов можно работать с кэшем, храня в нем целые страницы, их фрагменты или просто часто используемые данные. Легко заметить, что технология достаточно проста. Единственное, что мне хотелось бы мне еще раз сказать – обязательно проверяйте наличие объектов в кэше, перед тем как пытаться использовать их, или вашим обработчикам нештатных ситуаций придется все же выполнить свою часть работы.