Как правильно сформирование id-записи кэша?

StalkerClasses · 24 Дек 2013

Для кэширования страниц использую файлы.
Алгоритм очень простой - открыл файл, записал кэш.
Далее проверил если есть такой кэш, значит берем кэш.

Вопрос про то, к чему можно Универсально привязывать уникальный id-кэша?

Url адреса состоит из (пример) подобного
ЧПУ:
/company/news/32/page/1/
/company/news/date/2013/12/12/

Здесь получается есть
Id-страницы
Id-новости
№-страницы
Либо Дата...

Привязывать к примеру, к Id-страницы очень просто - проверил, есть ли такой id-страницы, значит индефикатор правильный... Если нет, выдал 404-ошибку...

Но как быть с более сложными адресами, вот например проверить адрес:
/company/news/32/page/1/ - еще можно, смотрим id-записи, и через извращенские sql-запросы проверяем позицию данной новости в навигационной цепочке...

Но если уже брать более сложные ЧПУ, то, проверять какждый этот введенный параметр, уже не представляется возможным...

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

Просто если не проверить валидность индефикатора кэша...
То пользователь введя к примеру
/company/news/32323232/page/13332blabla/

-- запишет мне новый кэш... что не очень то правильно.

accido · 24 Дек 2013

Кстати зачем вам генерировать айди кеша, если вы не хотите кешировать это "/company/news/32323232/page/13332blabla/". Не кешируйте.
Кстати, можно кешировать в соответствующие файлы и потом отдавать из апача или какой_у_вас_там_сервер. Пример для апача для ЧПУ:

Код:

<FilesMatch "\.html\.gz$">
  ForceType text/html
  Header set Content-Encoding: gzip
</FilesMatch>

RewriteEngine On
RewriteBase /
RewriteCond %{QUERY_STRING} !\?
RewriteCond %{REQUEST_URI} !^/?cache/ [NC]
RewriteCond %{REQUEST_URI} ^/?(.)(.*?)/?$ [E=CACHE:"cache/$1/$1$2.html.gz",NE]
RewriteCond %{ENV:CACHE} -f
RewriteRule ^/?(.)(.*?)/?$ /cache/$1/$1$2.html.gz [E=!CACHE,L]

StalkerClasses · 24 Дек 2013

accido написал(а):
Кстати зачем вам генерировать айди кеша, если вы не хотите кешировать это "/company/news/32323232/page/13332blabla/". Не кешируйте.
Кстати, можно кешировать в соответствующие файлы и потом отдавать из апача или какой_у_вас_там_сервер. Пример для апача для ЧПУ:

Код:

<FilesMatch "\.html\.gz$"> ForceType text/html Header set Content-Encoding: gzip </FilesMatch> RewriteEngine On RewriteBase / RewriteCond %{QUERY_STRING} !\? RewriteCond %{REQUEST_URI} !^/?cache/ [NC] RewriteCond %{REQUEST_URI} ^/?(.)(.*?)/?$ [E=CACHE:"cache/$1/$1$2.html.gz",NE] RewriteCond %{ENV:CACHE} -f RewriteRule ^/?(.)(.*?)/?$ /cache/$1/$1$2.html.gz [E=!CACHE,L]

Так при вводе такого битого адреса - кэш же записывать - будет...
/company/news/32323232/page/13332blabla/

accido · 25 Дек 2013

StalkerClasses написал(а):
Так при вводе такого битого адреса - кэш же записывать - будет...
/company/news/32323232/page/13332blabla/

Ну ок, закешируйте все, что у вас есть, а потом, если апач не найдет в кеше отдайте "не найдено".

Breeze · 25 Дек 2013

потом дайте адресок и место на диске внезапно закончится
такое только с вытесняющим кешом катит

кешируйте данные, этого достаточно

fixxxer · 25 Дек 2013

Это все ерунда (можно просто составить список правил по преобразованию в каноничные урлы на уровне роутера или даже генерировать конфиг nginx/apache с location-ами, вынеся проблему уровнем выше). Ты задумайся над таким вопросом лучше. Написали новость, обнаружили очепятку, исправили. Теперь при этом должен сброситься
1) кэш страницы с этой новостью
2) кэш страницы "последние новости"
3) кэши всех страниц, где сбоку показываются 5 последних новостей
4) rss
...

StalkerClasses · 25 Дек 2013

L

fixxxer написал(а):
Это все ерунда (можно просто составить список правил по преобразованию в каноничные урлы на уровне роутера или даже генерировать конфиг nginx/apache с location-ами, вынеся проблему уровнем выше). Ты задумайся над таким вопросом лучше. Написали новость, обнаружили очепятку, исправили. Теперь при этом должен сброситься
1) кэш страницы с этой новостью
2) кэш страницы "последние новости"
3) кэши всех страниц, где сбоку показываются 5 последних новостей
4) rss
...

+ постраничная навикация, и в итоге вся страница, где работает этот плагин...
и еще если есть sitemap.xml...

А если еще учесть, что все это могут редаткритьвать несколько человек.

В любом случае так понимаю, что кэширование как "концепцию" - использую для уменьшения нагрузки на сервер и увеличения повторного обращения к странице...

Пробобую разработать подобную логику на сайте...
Но как ее потом в памяти удержишь...
Думаю что это актуально только для больших и очень посещяемых проектов.

Взять к примеру этот форму...
Здесь при добавлении записи (поста) - ведь по идее же тоже куча всяго сбрасывается и в разных местах.

Breeze написал(а):
потом дайте адресок и место на диске внезапно закончится
такое только с вытесняющим кешом катит

кешируйте данные, этого достаточно

О, а об этой идее даже и не думал...
Т.е. получается надо кэшировать не сами страницы в файлы, а запросы к БД...
По идее производительность от этого не сильно упадет..

Но так понимаю, что по идее придется все равно как-то закрывать страницы на 404-ошибки... Если запрос прошел удачно, кэширование разрешаем, не удачно... Надо как-то от этой идеи отказаться, что бы привязываться к чему-то...

По идее запрос успешен - значит разрешаем кэшировать...
Не все же подряд кэшировать.

StalkerClasses · 25 Дек 2013

accido написал(а):
Ну ок, закешируйте все, что у вас есть, а потом, если апач не найдет в кеше отдайте "не найдено".

Так много же может всего получиться
/page/blblblba/
/page/1.blblblba/
/page/2.blblblba/
/page/3.blblblba/
...
/page/10000000.blblblba/

И так далее, так и сайт "завалить" можно...

hell0w0rd · 25 Дек 2013

Что за жесть? У вас задача - написать генератор статических страниц.
Перекладываете раздачу статики на апач/енжинкс, а в админке при сохранении - генерируете новую страницу.
И я не понимаю в чем проблема инвалидировать такой кеш. Если раньше rss отдавался php скриптом - то теперь при обновлении нужно просто исполнить этот скрипт.

Breeze · 25 Дек 2013

т.е. ты можешь кешировать целиком страницу, иногда! в этом ничего страшного нет, но не отдавать ее напрямую с диска, т.к. тебе в любом случае придется решать три задачи:
1. своевременная инвалидация кеша
2. инвалидация в условиях конкурентного доступа
3. убирать старый, никому не нужный кеш

ключи можно именовать по виду category:1234

age:1 и перед сохранением проверять на допустимые диапазоны и т.д.

Breeze · 25 Дек 2013

hell0w0rd написал(а):
И я не понимаю в чем проблема инвалидировать такой кеш

инвалидируй 1000 статичных страниц, отдаваемых нгинксом, кнопкой из админки, пожалста =)

Breeze · 25 Дек 2013

разумеется, что при определенных условиях 5-10 минут в задержке обновления -- ничего страшного, но редакторов это будет подбешивать

Breeze · 25 Дек 2013

и еще, отсутствие чего-то в кеше не повод показывать 404 ошибку

Gas · 25 Дек 2013

>ничего страшного, но редакторов это будет подбешивать

а редакторы пусть работают с отключеным кешированием, их 3 калеки - нагрузки не создадут и подбешивать не будет,
жать только что кеширование страниц целиком редко когда возможно

Breeze · 25 Дек 2013

Gas написал(а):
а редакторы пусть работают с отключеным кешированием, их 3 калеки - нагрузки не создадут и подбешивать не будет,
жать только что кеширование страниц целиком редко когда возможно

зачем, если с их помощью можно еще и контроль осуществлять =) просто не надо заставлять ждать эти 10 минут, сохранил, пошел смотреть и увидел все на своих местах.
если нет, то есть проблема

StalkerClasses · 25 Дек 2013

Мне очень понравилась идея кэширования именно mysql-запросов...
Обычно когда кэш пишется в файлы, то индификатор создается так:

$cacheID = "news_" . $GLOBALS['_GET']['news_id'].
Здесь мы можем проверить $news_id - в базе данных...
Если есть, то разрешаем писать кэш, если нет - 404-ошибка

А если _GET-более сложный - например дата/число/месяц/№страницы/№записи...
То проверять весь этот _GET-это уже слишком сложно, и это еще не самый сложный пример....

И по этой причине, как полагаю, что наверное имеет в этом плане смотреть именно в сторону кэширования запросов...

hell0w0rd · 26 Дек 2013

Ну, как самый простой вариант - использовать xslt/json-аналоги. В таком случае все данные можно хранить в xml/json файлах, а также необходимость в инвалидации отпадает.
А если стандартно кешировать просто сгенерированную страничку - в чем проблема? У на есть все роуты - обходим их, генерируем ответ, сохраняем.

fixxxer · 26 Дек 2013

StalkerClasses, да, примерно так, осталось придумать механизм инвалидации

Погугли memcached tags.

Ну и кэшировать надо не на уровне контроллера, а на уровне моделей.

StalkerClasses · 14 Янв 2014

fixxxer написал(а):
StalkerClasses,
Ну и кэшировать надо не на уровне контроллера, а на уровне моделей.

Хотел поинтересоваться, а ведь правильно понимаю, что кэшировать на уровне моделей (т.е. так понимаю это извлечение данных из БД) - имеет смысл только тогда, когда там определены "довольно сложные и емкие mysql-запросы"?

Т.е. кэшировать на уровне моделей что-то типа SELECT * FROM table WHERE ... не имеет смысла?
И проще закэшировать вывод HTML-кода как в шаблон, и после проверять есть ли кэш этого шаблона, или нет.

Breeze · 14 Янв 2014

Если кешировать, то все запросы. Если датабазная либа умеет connection on demand, то выигрыш будет хорошим.
HTML кешировать проще, но тут заодно всплывает дублирование данных и увеличение объемов, а соответственно снова инвалидация =)

Как правильно сформирование id-записи кэша?

Новичок

Новичок

Новичок

Новичок

goshogun

К.О.

Новичок

Новичок

Продвинутый новичок

goshogun

goshogun

goshogun

goshogun

может по одной?

goshogun

Новичок

Продвинутый новичок

К.О.

Новичок

goshogun