Вопросы по HTTP Кэшированию

В случае когда вам нужно закешировать страницу на стороне клиента. Как использовать? - по моему в статье об этом написано.

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

Про "Алгоритмы" написано в статье

По поводу реализации, все зависит от вашего ПО, погуглите, например, "nginx кэширование"

Извиняюсь, но я не совсем корректно задал Вам вопросы))

Я имел ввиду как грамотно переделывать заголовки последнего изменения страниц. Со страницами в духе "Контакты" вроде все понятно, а вот как обстоят дела с страницами в духе "Мой профиль". Хранить данные в сессии? Или может быть есть другие более рациональные решения? А может вообще не стоит их так кэшировать?

Прикрепляю один модуль для CMF Kohana. Может быть благодаря ему Вы полностью поймете меня)) Прошу не судить строго за сам модуль, если там все очень плохо. Прошу совета какого-нибудь дабы направиться на путь истинный ;) Если есть готовые решения также, прошу поделиться))

P.S. Использую связку PHP + MySQL + Apache вместе с CMF Kohana.

---------- Добавлено 04.02.2014 в 21:19 ----------

Вот ссылка на модуль: http://yadi.sk/d/hPCYeeB8HKEWx

а что значит грамотно? как хотите (считаете нужным) так и поступайте, или вы хотите чтоб вам подсказали как нужно? а кто ж знает как вам нужно? если например контент храниться в бд, то дата добавления этого контента в бд может быть переделанной датой последнего изменения страницы, но вдруг вы внесете изменения в шаблон, а в кеше останеться старый вариант??

имхо, если вы хотите снизить нагрузку на сервер путем кеширования страниц, то время кеширования стоит определять час, два не более, а вообще, я бы не парился с "кешированием" в php, а вот кеширование запросов к БД это можно, но для этого, как правило, хватает внутренних средств самого сервера БД (по крайней мере в MySQL)

ну еще можно кешировать статичные картинки, js, css и т.п., но опять же не надолго, а то вдруг надо будет внести изменения

Имхо - статья ни о чём, галопом по европам. Типичный пример современного рерайта.

В сжатом виде про кэширование на стороне клиента глянь тут и далее - по ссылкам в посте.

Кэшировать нужно динамические страницы, тк статические(а так же .css, .js и картинки) - Веб-сервер кэширует сам по дате последнего изменения файла.

Динамические страницы(грубо говоря .php) Веб-сервер так кэшировать не может, тк данные для формирования страницы берутся из БД(обычно) и дата их изменения ему не известна. Дата изменения файла.php ни о чём не говорит.

Вопрос кэширования на стороне клиента критичен если на сайте десятки тысяч страниц(для быстрой переиндексации изменений). Для 200-300 страниц вменяемого размера кэширование не актуально, тк интернет-каналы сейчас достаточно "толстые" и по большей части - безлимитные и экономить трафик клиента особо не зачем(достаточно сжатия страниц при отправке).

Также, кэширование(точнее - отключение кэширования) актуально для админок, чтобы сразу показывать внесённые изменения, и случайно не поднять старую страницу из кэша браузера. Но отключение кэширования делается намного проще.

Я так понимаю, что на больших проектах: с большим количеством динамических страниц, от HTTP кэширования лучше отказаться....

Наоборот, на больших проектах с динамическими страницами актуален вопрос быстрой переиндексации изменившихся страниц. А роботы ПС:

- имеют лимит по количеству url, индексируемых с сайта за один раз

- поддерживают кэширование на стороне клиента (IfModifiedSince - LastModified)

Поэтому, получив ответ "304 Not modified"(страница не изменилась с даты последней индексации) робот ПС тут запрашивает следующую.

И своё суточный лимит по индексации робот выбирает именно новыми изменившимися страницами сайта.

PS: Актуально для Яндекса(и, наверное, mail.ru), у Google много роботов и ресурсов, он и так достаточно быстро переиндексирует сайты.

Всем большое спасибо за информацию))