Хитрости кеширования

В этой заметке, являющейся продолжением двух предыдущих («кешируем свой сайт» и «кеширование динамического сайта»), мы поговорим о некоторых трюках, которые могут помочь при создании кешируемого сайта, а также попробуем ответить на часто встречающиеся вопросы.

Одна из самых важных вещей, которые необходимо понять при организации кеширования страниц, заключается в том, что каждый файл кешируется по отдельности. Например, если у вас есть html-страница, содержащая картинку (<img src=»http://www.myhost.ru/img/pic.gif»>), то браузер выполнит два запроса — один для страницы и второй — для картинки. При этом никто не мешает вам указать для каждого из этих файлов разное время модификации и разное время жизни.

Это может оказаться полезным во многих случаях. Например, если вы создали онлайновую картинную галерею, то можете указать большой срок кеширования для графических файлов — скажем, несколько месяцев — и относительно короткий для html-страниц. При этом, если вы захотите изменить «обрамление» своей галереи или добавить новые картины, то в течение сравнительно небольшого времени html-файлы обновятся во всех кешах, а вот «тяжелые» картинки будут загружаться по-прежнему быстро — ведь они как лежали на кеширующем прокси, а то и в локальном кеше браузера, так и продолжают лежать!

Это же свойство можно использовать и для того чтобы избежать двух основных недостатков кеширования: проблем с показом рекламы и с подсчетом статистики.

Со статистистикой все относительно просто: достаточно включить в страницу, например, вызов какого-нибудь прозрачного GIF’а размером 1х1 пиксель, а потом смотреть access.log вашего веб-сервера. Причем никто не мешает этот GIF выводить также скриптом, который попутно будет, например, заносить данные о посещениях в базу данных, устанавливать cookies или производить еще какие-то действия. Можно даже картинку делать не 1х1, а динамически рисовать цифры посещений и показывать их на странице. Надо только не забыть сделать так, чтобы эта картинка в свою очередь не кешировалась.

Показ рекламы организовать тоже не очень сложно. В случае баннеров все делается так же, как и со счетчиком, а если вы выводите текстовую рекламу, то проще всего сделать так, чтобы ваш рекламный скрипт генерировал код JavaScript, а в самой страничке вставить, скажем,
<SCRIPT LANGUAGE=»JavaScript» SRC=»http://www.myhost.ru/advert.cgi?page=article14″></SCRIPT>

Для того чтобы картинки счетчиков или рекламы не кешировались, можно либо читать их с диска скриптом, а потом выводить соответствующие заголовки (как Content-Type, так и все имеющие отношение к кешированию), либо настроить свой веб-сервер таким образом, чтобы он автоматически выдавал «некеширующие» заголовки для нужных картинок. В частности, для Apache нужно включить mod_expires и mod_headers (оба эти модуля есть в стандартной поставке сервера, но по умолчанию выключены), сложить картинки, которые не должны кешироваться, в отдельную директорию и создать в ней соответствующий .htaccess файл. Например, такой файл может содержать строки:

ExpiresActive On
ExpiresByType image/gif A1

Первая строка включает mod_expires для данной директории, а вторая устанавливает Expires в 1 секунду после времени запроса файла для картинок в формате gif. Более подробно о настройках этих модулей можно (нужно!) прочитать в документации.

Настраивая кеширование, надо тщательно оценивать значения, которые вы выставляете — после того как страница была сохранена в каком-то кеше, у вас уже не будет возможности уменьшить время ее жизни, и в случае изменений на сайте посетители будут продолжать получать устаревший документ.

Динамическим сайтам может пригодиться и еще один трюк. Дело в том, что довольно большое количество посетителей заходят на сайт напрямую, минуя прокси. А это означает, что для каждого запроса ваш сервер должен, например, подключиться к базе данных, передать запрос, прочитать результат, обработать его, вывести… А как правило, значительное число запросов повторяется
, и страницы выводятся все те же… Так почему бы не организовать свой прокси, который будет заниматься кешированием вашего сайта? Причем он вполне может находиться на той же машине, что и сам сервер (разумеется, это зависит от нагрузки). Подобное решение способно очень значительно (на порядки!) снизить загрузку сервера, а поскольку вы полностью контролируете кеширование (как со стороны сервера, так и со стороны прокси), то сможете все отстроить так, чтобы максимально использовать преимущества кеширования и избежать его недостатков.

В принципе, чем более популярен сайт, тем больший эффект дает кеширование. Связано это с тем, что объем данных, которые может содержать кеширующий прокси, ограничен (диск-то не резиновый!), и данные, которые редко запрашиваются, с большей вероятностью будут удалены из кеша, даже если их время жизни еще не истекло. Поэтому, подготавливая свой сайт к кешированию, в первую очередь присмотритесь к тем страницам, которые вызываются чаще всего.

И еще одно важное замечание. Что бы вы ни делали, избежать кеширования вы не сможете. Более того, вы не сможете гарантировать, что все клиенты увидят свежую копию сайта — например, в какой-то локальной сети админ для экономии трафика может заставить свой прокси игнорировать все ваши установки о времени жизни страниц. Или, что еще «веселее», банально скопировать ваш сайт каким-нибудь «телепортом» и выложить в своей сети. Причем такие копии могут жить годами… Поэтому, меняя структуру сайта, не поленитесь сделать скрипт, который будет вызываться при 404-й ошибке, разбирать адреса запроса и перенаправлять посетителя на новую страницу (в Apache для этого используется директива «ErrorDocument 404»).

Ну, а для того чтобы посмотреть, как происходит общение между браузером и сервером, очень удобно использовать программу HTTPLook или онлайновый Show Headers Tool (это удобнее, чем «телнетиться» на 80-й порт и вручную давать запросы серверу). Кроме того, стоит воспользоваться онлайновым сервисом Cacheability Engine Query, который даст достаточно подробную информацию о том, насколько хорошо будут кешироваться страницы.