Парочка обновлений на сайте/форуме - Появился новый плагин, "Ошибки 404" (подробнее). - Появился новый плагин, "Полностраничный кеш" (подробности)! Давно хотел написать, но как-то руки не доходили. В результате получилась достаточно удачная реализация, даже немного горжусь
http://www.w3.org/Protocols/rfc2616/rfc ... #sec10.3.1 http://www.w3.org/Protocols/rfc2616/rfc ... l#sec14.44 как происходит инвалидация кэша?
sword dancer 1. Это не поможет, т.к. движок определяет язык клиента, исходя из целой кучи факторов (заголовок Accept-Language, куки, адрес домена для мультисайтовых проектов). Все это средствами HTTP не решишь. И еще один важный момент: речь о том, как методами mod_rewrite перебросить запрос на конкретный файл. Как ты предлагаешь в правилах для mod_rewrite учитывать все эти заголовки? 2. Никак, страницы кешируются "навсегда". В админке есть ссылка "очистить полностраничный кеш", которой рекомендуется воспользоваться после внесения каких-либо изменений на сайте. TTL здесь, имхо, бесполезен - мы же по определению кешируем страницы без динамики - а что-то сложнее мутить не хочется.
Насколько я понял, в таком случае сайт превращается в кучу нагенереных движком HTML-ек... ИМХО, мало кому такое нужно, особенно на настолько высоконагруженных проектах.
sword dancer Да, а что такого? Грохнуть кеш - операция элементарная, а восстанавливается он не одновременно, а по мере запроса страниц посетителями. Частичная очистка кеша, тем более автоматическая - штука чреватая трудноуловимыми багами. Я в таких случаях предпочитаю наиболее простые решения. Clone В предельном случае - да. Но можно, например, закешировать одну главную страницу сайта (на которую обычно и падает основная нагрузка), а остальные оставить в покое. Бывают и полностью статические сайты, для которых чем ниже нагрузка - тем лучше. Все зависит от конкретного случая.
Dagdamor, насколько предельным должен быть случай? Миллион уников в сутки, наверное... Ну и кешировать целиком главную, где по сути аггрегирована инфа со всего сайта... Неразумно, имхо. Я сам на оптимизацию главной страницы потратил больше времени чем на другие, но её я кеширую лишь крайне частично.
Clone Внутреннее кеширование - это отдельная песня, для него в движке есть свои методы. Прелесть полностраничного кеширования (по крайней мере в нынешней реализации) именно в том, что страница отдается не движком, а непосредственно веб-сервером. Кроме реального снижения нагрузки на сервак, это также означает, что Апач будет корректно отдавать заголовки, связанные с кешированием, такие как Last-Modified, E-Tag (что в ряде случаев снизит и траффик), а также сможет отдавать контент по частям (Accept-Ranges), с поддержкой докачки. Все это мелочи конечно, но приятные. А уж как им пользоваться (или не пользоваться вообще) - зависит от конкретного проекта и его разработчика, тут общих выводов быть не может.
Отдавать HTML по частям?о_0 Ваще полностраничное кеширование штука канеш полезная, но реальной необходимости я, чес гря, ещё ни разу не встречал...
"такого" тут в том, что "идти и грохать кэш" рано или поздно задалбывает. и сразу после очистки валится куча тяжёлых (не закэшированных) запросов - фактически досим сами себя руками клиентов. вместо того, чтобы прикрутить к своему движку событийную модель, правильно реагирующую на изменение ресурсов, ты нагружаешь пользователя необходимостью вручную генерировать малоинформативное событие "я что-то изменил в системе, поэтому грохните, плиз, этот дурацкий кэш".
Я вот все жду возможность, чтобы можно было его устанавливать в папку, а не в корневой каталог. Демку глядел - понравилось Но копаться пока лень.
Отсюда. Кошмарики. P.S. Dagdamor, а ещё у тебя кэш ужасен. Код (Text): $cache = $optimizer->processFileCache('test', OneHour, 'callbackFunc'); Во-первых, почему бы не OneHour, а +1 hour (strtotime() рулит). Во-вторых, его нужно чистить руками из админки. Это типа дурной тон, да.
Не вижу никаких ужасов в префиксах, не нравится, можно не использовать, нравится - используй. В Doctrine, например, существует три способа доступа к объектам, кому какой нравится, тот такой и выбирает.
Хотя Dagdamor и использует термин CMF для PHPC, но такие элементарные вещи, как установка в субдиректории (аж до 2.5.0) и отсутствие префиксов... CMF должна помогать, а не диктовать условия потому что автору лень что-то доделать. Любой движок должен содержать какую-то идею и правила. Вроде договора о пространстве имён или стили кодирования, может имёть чёткие принципы, когда дело касается тех или иных фич (или их отсутствия), но ограничивать использование потому что гладиолус - это не правильно. P.S. + к тому что не понравилось: комшарный html-like синтаксис. Он косит под html, но с какими-то синтаксическими наворотами вроде тега в теге.
lexa Насчет "кошмариков" - я по-прежнему придерживаюсь все той же точки зрения. Сваливать несколько разных проектов в одной БД - не есть гуд. Поддержки префиксов в PHPC нет даже в планах. Дешевый хостинг с одной БД - пользуйтесь доктриной (если потянет на таком хостинге, конечно). Насчет установки в субдиректории примерно то же самое, лично мне это никогда не было нужно, а вы не забывайте, что движок я пишу все-таки для себя самого в первую очередь, и реализую те функции, которые нужны мне. Люди начали всерьез требовать установку в подкаталог только после выхода версии 2.4.5 (нынешней). Хорошо, будет вам установка в подкаталог. Но в следующей версии. Это как раз 2.5.0 и будет. Еще раз, я ограничиваю что-то не потому, что гладиолус, а потому что мне, в моих проектах, это не нужно. Если я сейчас начну реализовывать первое, что захочет Леха, фреймворк заболеет элефантизмом Насчет кеширования непонятно. Файловый кеш хранится не до ручного удаления в админке, а до срока устаревания, тот же самый OneHour. Это срок жизни кеша. При чем тут "+1" - не понял. В админке - всего лишь дополнительная функция для удобства. Она вызывает $optimizer->clearFileCache(); Никто не мешает тебе точно так же вызвать этот метод из своего кода, когда это необходимо. Сам движок для своих нужд файловый кеш не использует.
Ты так привязался к идеи об "одном проекте", что совсем забываешь, что "один проект" может включать движок, форум, чат и т.д. и т.п. Мне на каждый компонент сайта заводить БД? Или подменять его реализацией на PHPC что ли? А если у меня сначала был форум и я не использовал префиксы для его таблиц, а теперь хочу ввинтить в него PHPC, что прикажешь делать? Ведь PHPC использует очень оригинальные имена вроде sessions, settings, templates. Фреймворк это библиотека, она должена помогать расширять, а не указывать. Ты называешь движок фремворком, ты используешь библиотечную лицензию (LGPL), но движок диктует правила, которые библиотекам и фреймворкам чужды. И напрасно ты на меня наговариваешь. Я ведь заметил, что любой движок должен содержать ряд правил (идей) в том числе авторскую идею развития. Это лекарство от элефантизма и я это поддерживаю. Про кэш. +1 hour это strtotime('+1 hour'). То, что он удаляется по истечению срока жизни понятно. Но как мне удалить/обновить кэш по ключу? В классе Optimizer я такой возможности не увидил. Если у меня сотни файлов, то мне сотни файлов удалять чтобы удалить/обновить один? Файловый кэш медленный, а в процессе удаления большого кол-ва файлов можно повесить весь сервер. Тем более, что весь кэщ хранится "плоско", без поддиректорий. P.S. Кстати, а почему выбрал LGPL, а не MIT, BSD или GNU?
Лицензи нужны чтобы оговорить права и обязанности сторон: разработчика(ов) и пользователей. Что могут и не могут обе стороны. Как можно использовать, а как нельзя. Чем можно ограничевать разработчику(ам) пользователей, а чем нельзя. Все лицензии оберегают автора кода паралельно оберегают и права пользователя. Автор есть автор. Если вы что-то изменили, то вы тоже автор, но изменения. Пользователь есть пользователь. Но у него такие же права на распространение, доработку и т.д., как и у автора. Каждая лицензия делает код общественным достоянием. Это как если бы вы изменили музыку Бетховена и исполняли её. Значит пишите "Музыка Василия, на основе сонаты Бетховена". Людвиг ван не против, не против и автор кода. Это суть. Важный момент также заключается в конфликтах лицензий. BSD и MIT лицензии разрешают пользовать продукт в программах идущих под иной лицензией. Коммерческой или нет - не имеет разницы. Это самые простые для понимания лицензии. GPL не разрешает такого и вообще для понимания она проблемна (ИМХО, но я с ней долго разбирался). Любая часть кода под GPL использованная в программах с другой лицензией распространяет лицензию на весь код в котором используется. В итоге GPL как вирус охватывает весь код. Я люблю эту лицензию. Ну и LGPL. Эта лицензия что-то среднее. Она мягче GPL только в том плане, что позволяет подключать программы распростанённые под ней в программы со своей лицензией. То есть, программа под LGPL на самом деле программа как бы под GPL, но не распространяется, как вирус. На примере. Есть форум SMF. Его нельзя использовать с продуктами под GPL. Но можно под BSD и MIT. А так же в него можно инклудить продукты под LGPL, но нельзя обратного: инклудить в продукт под LGPL форум SMF потому что будет конфликт лицензий. P.S. Наглядный пример проблемы лицензий это движок DataLife Engine. Это платный движок со своей лицензией. Так вот, изначально он был вилкой движка CuteNews шедшего под GPL. Потом много лет прошло, автор DLE сменил лицензию, но оставил функцию из CuteNews в основном файле, который инклудится во все файлы (а те ещё дальше) движка. Следовательно, DLE на самом деле имеет лицензию GPL. И проблема действительно большая. На территории РФ правовые действие GPL ставят под сомнения, но на территории Германии, где живёт автор DLE, GPL цветёт и пахнет. Если кто-то подаст на автора DLE в суд, то без труда выйграет дело, т.к. доказать что он использует код GPL не составит труда. upd не очень-то коротко получилось.