Прямо уж многочисленным Считаю, что идея бесперспективная: 1. Это придумано для статического контента (картинки файлы флешки), а не для страниц. 2. Современные сайты все динамические, там нечего особенно кешировать. 3. У многих посетителей браузер настроен так, чтобы дергать новую версию страницы в любом случае (в Опере например так сделано по умолчанию). 4. Про ботов я вообще молчу, станут они рисковать недополучить контент, посылая сомнительный заголовок. 5. Протокол очень уж неудобен для программиста, при реализации возникает куча подводных камней, почитать те же мучения автора с датами последних сообщений. Чтобы добавить поддержку этого протокола, ему пришлось внести изменения в логику работы проекта (вместо удаления тем они у него стали помечаться удаленными), а это никуда не годится. 6. Если проект прямо таки загибается от нагрузки на сервер и нужно кеширование HTML, делается обычный Full Page Cache: движок сайта, сгенерировав страницу, сохраняет ее в виде файла, и в .htaccess делается условие для mod_rewrite. Если файл есть - он отдается Апачем (и пусть он и возится со всеми заголовками). Если файла нет - только тогда стартует движок.
armadillo На многих сайтах смешаны блоки статичной, динамичной и персонализированной информации. Поэтому выдать кешированную страницу просто не получается. Если с персонализированное + статичное можно выдать, то уж точно не с динамическим блоком, который обязан обновлятся постоянно. Да, где-то этот подход подойдёт, но таких мест довольно мало. В наше время в основном идёт динамическая генерация контента с использованием кеширвания отдельных блоков.
Горбунов Олег Это я к тому, что незачем встраивать поддержку CG в движок. Много телодвижений, мало толку... этим вебсервер должен заниматься, а не несчастный программист. А в случае Full Page Cache мало того, что уменьшается нагрузка на сервер, но и также падает траффик - ведь страница, сохраненная в виде файла, уже является статическим контентом, и Апач может применять к ней любые методы кеширования - в том числе и Conditional Get. Просто это происходит автоматически.
Psih это понятно. Но стоит расписать какие блоки как стоит кешировать. Возможно динамику вынести во фрейм или аякс (знаю что рекламщики будут возражать), и что тогда будет с кешем - тоже. Кеш апача работает по времени, а не обновлению данных, он нужен, но не отменяет остальное. Возможность отсылать только заголовок слишком заманчива, чтобы от нее сразу отказываться. Пример автора - не обязательно самый удачный.
как чем? у браузера есть кэш, у прокси есть кэш, у нас на сервере есть кэш. давайте будем их хоть иногда юзать, а?
у браузера - не от нас зависит. наша прокся и апач - годятся для статики. Ветка как кешировать динамику, не передергивай.
> браузера - не от нас зависит. зависит. у тебя неверная информация. > наша прокся и апач - годятся для статики. Ветка как кешировать динамику ими же. если у тебя есть желание послушать - я могу объяснить...
Как кешировать на уровне приложения? Как пример, приведу свой трекер (file.lv) 1). На уровне SQL запросов - это когда результат запроса собирается в массив и запихивается в memcache/apc/xcache/фаил на какое-то время и при следующем запросе данные берутся уже оттуда. Вот моя функуия, которая это делает: PHP: <?php function cache($query, $rehash = 180, $key = null){ global $mem; if ($key != null && !empty($key)){ $id = $key; }else{ $id = md5($query); } if (!$data = $mem->get($id)){ $result = mysql_query($query); $data = array(); if (mysql_errno()){ _debug(mysql_error()."\n\n".$query); } while ($row = mysql_fetch_assoc($result)){ $data[] = $row; } $mem->set($id, $data, false, time()+$rehash); } return $data; } Простейший вариант, без лишних ухищрений. $mem - это объект Memcache Есть ещё 2 вариации этой функции с названиями cache_row() и cache_single() Эти функции у меня применяются для кеширования кол-ва сообщений в Inbox/Outbox, флага есть ли новые сообщения (при отправке собщения пользователю в скрипте этот флаг стирается, что заставляет заного проверить наличие новых сообщений), хранения кол-ва страниц и.т.д., много для чего. 2). Кешировать блоки HTML'a. Аналогично привещему, только требуется дополнительная логика что бы проверять есть ли HTML, и если его нету - генерировать, сохранять и выводить юзеру. Пример блоков на моём трекере: Шапка с меню и низ сайта - статика. Блок с информацией об акаунте - частично статичная, но уникальная для каждого юзера информация. Такую надо переодически обновлять, но каждому юзеру блок свой - если кешировать всё - зашъёшься. Посему кеширую на уровне SQL на минут 10-15 где-то. Динамические блоки - список, описание торрентов, комментарии. Там применяю кеширование HTML'a на определённый интервал. В списке забил на актуальность данных - кеш обновляется каждые 3 минуты - и если торрент добавили, то он появится только когда обновится кеш. Да, не совсем понятно, но юзеры этого даже не замечают да и 3 минуты долго ждать не нужно. Описание торрента - там легче, закешировал на часик какой HTML и выводи себе спокойно. А вот с комментами беда - однако я выкрутился и тут Если интересно, просите - опишу как. А щас откланиваюсь и иду спать
Ну так вот, продолжу. Есть такая вещь - комментарии. Да и не только они. Сюда-же может входить и форумы, гостевые книги и всякая такая чепуха. На первый взгляд это не возможно кешировать, если у вас есть разные статусы с разными возможностями по управлению этими самыми комментариями. Владельцы могут их редактировать, модераторы удалять, редактировать. И.т.д. На первый взгляд для каждого юзера надо иметь свой кеш, что не только не разумно но и приводит к очень большому кол-ву данных - 1 юзер = много кешей (если у вас одна ветка). Тут на помощь приходит JavaScript Вместо расставления кнопок на уровне генерации PHP кода, я сделал кеш по уровням доступа: Юзеры и Модераторы. У модераторов генерируются все кнопки сразу и так и ложится в кеш. А вот для юзеров генерируется JS массив, где прописывается для каждого сообщения кто его владелец и есть глобальная переменая, в которой хранится ID текущего пользователя (смотрящего страницу). При загрузке страницы JS раставляет нужные кнопки где надо в span'a, помеченные ID'ками сообщений. В итоге получаем закешированный HTML для комментариев, но в то-же время динамическое генерирование кнопок по управлению сообщениями. Simpe, but fast!
Psih, думаю в этом случае было бы достаточно в зависимости от типа пользователя менять класс у body, а уже css-ом разрулить что надо показывать, а что - нет.
non javascript users в топку. хтмл в виде js как на fastbb.ru - хорошая тема, но ветка о том как разгрузить сервак от запросов.
> хтмл в виде js как на fastbb.ru - хорошая тема ужасная тема. боже упаси в таком чуде править хтмл-баги или даже, чур-меня, менять вёрстку...
armadillo Все поисковики и большая часть мобильных браузеров... а давайте для себя одного сайты писать, а?
Мы здесь не говорим о поисковиках, ага. Мы здесь не говорим о мобильных устройствах, ага. Мы говорим о кешировании и возможных его методах, ага. [offtop] Если вы планируете, что ваш сайт будут смотреть с мобильных устройств - сделайте XHTML версию облегчённую для них. Да и как-то можераторский функционал расширенный для мобильного устройства - вы извращенец батенка. К тому же, если вы не заметили, для модераторов я генерирую всё на уровне PHP [/offtop]