URL: https://www.opennet.ru/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID8
Нить номер: 1946
[ Назад ]

Исходное сообщение
"Dynamicly composed pages, cache, fs"

Отправлено Александр , 11-Дек-03 18:16 
Народ, помогите, пожалуйста, разрешить следующую проблему:
- хочется харнить кеш-копии сгенерированных страниц, и посчитанных данных
- хочется добавлять, например, к новостям, картинки

Соответственно и то и другое - на файловой системе.

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

Если просто создать, скажем директорию news, и в ней создавать директории по номеру новости, и складывать все аттачи в неё, то не начнуться ли проблемы, скажем на 10'000 новости (а их уже реально 5'000)?
То же относится и к кешу... Только его можно переиодичски чистить, а вот чистить аттачи к новостям... - пользователи не поймут =)

Единственное решение, которое мне удалось придумать, это ввести некоторый коэфициент деления - например, 400 - тогда аттачи к новостям будут сохраняться в примерно таком виде - /news/0-400/138/SomeAttach.jpg

Кто что скажет?
Заранее благодарен,
/Александр.


Содержание

Сообщения в этом обсуждении
"Dynamicly composed pages, cache, fs"
Отправлено Александр , 11-Дек-03 20:58 
Вообще-то специально для хранения данных и придумали базы данных. В твоем случае она подходит как нельзя лучше. Аттачи лучше класть в разные директории, если их много. Допустим создать 1000 директорий с 000 по 999 и в них раскладывать аттачи. Вообще системам *nix пофигу, сколько файлов у тебя в директории, просто чем их больше, тем дольше будет поиск. Это проявляется где-то тысяч с 10 файлов(примерно).

"Dynamicly composed pages, cache, fs"
Отправлено Александр , 11-Дек-03 21:44 
>Вообще-то специально для хранения данных и придумали базы данных. В твоем случае
>она подходит как нельзя лучше. Аттачи лучше класть в разные директории,
>если их много. Допустим создать 1000 директорий с 000 по 999
>и в них раскладывать аттачи. Вообще системам *nix пофигу, сколько файлов
>у тебя в директории, просто чем их больше, тем дольше будет
>поиск. Это проявляется где-то тысяч с 10 файлов(примерно).

Спасибо за ответ.
Только вот с базой данных - не совсем то, что надо.
Задача - кешировать сгенерированые страницы, чтобы лишний раз не лезть в базу, и чтобы она не пухла как минимум вдвое + снизить время генерации, и хочется хранить кеш в файлах (например, наиболее популярные новости; старые - чистить, базируясь на времени последнего обращения).

Кроме того, есть функции, которые в результате своей работы делают порядка 10 запросов к базе, да ещё и над ними работают - результат их работы также хочется складывать в кеш (получается немного "проапргрейденный" кеш запросов). Но вот если что у первых, что у вторых принцип работы одинаковый (имя файла/функции - директория; аргументы - имя файла и возможна периодическая зачистка), то вот с аттачами так не получится...

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


"Dynamicly composed pages, cache, fs"
Отправлено Александр , 12-Дек-03 16:32 
На самом деле, вопрос о большом кол-ве файлов в директории решается.
Вместо линейного поиска в директории используются хэши.
Для FreeBSD(ufs) - это опция UFS_DIRHASH в ядре, для Linux(ext3) патч htree.
Причем для Free эта опция уже включена по умолчанию начиная с версии 4.5.

Так, новость с аттачами можно представить в виде директории с именем news_id, в которой будут лежать аттачи.
Объекты в кэш можно класть по мере обращения к ним, также удалять несвежие из кэша по прошествии некоторого времени.

Также, можно вопрос с кэшированием запросов оставить БД. У mysql 4 уже есть поддержка кэширования запросов.


"Dynamicly composed pages, cache, fs"
Отправлено Александр , 12-Дек-03 18:11 
>На самом деле, вопрос о большом кол-ве файлов в директории решается.
>Вместо линейного поиска в директории используются хэши.
>Для FreeBSD(ufs) - это опция UFS_DIRHASH в ядре, для Linux(ext3) патч htree.
>
>Причем для Free эта опция уже включена по умолчанию начиная с версии
>4.5.
>
>Так, новость с аттачами можно представить в виде директории с именем news_id,
>в которой будут лежать аттачи.
>Объекты в кэш можно класть по мере обращения к ним, также удалять
>несвежие из кэша по прошествии некоторого времени.
>
>Также, можно вопрос с кэшированием запросов оставить БД. У mysql 4 уже
>есть поддержка кэширования запросов.

Отлично, я убедился том, что сделано всё правильно =)
Только два последних вопроса:
- можно ли написать что-то для собственного хешироани файлов (чтобы не зависеть от системы)? Изначально сайт написан на php, но если надо, могу написать на Си програмулину, которая будет заниматься только этим.
- где копать про кеширование у 4-го mysql?


"Dynamicly composed pages, cache, fs"
Отправлено dev , 12-Дек-03 23:18 
>Отлично, я убедился том, что сделано всё правильно =)

А не проще поставить готовый кеш между клиентом и сервером? squid?


"Dynamicly composed pages, cache, fs"
Отправлено Александр , 13-Дек-03 04:21 
>>Отлично, я убедился том, что сделано всё правильно =)
>
>А не проще поставить готовый кеш между клиентом и сервером? squid?

Мы простых путей не ищем! =)
А если серьёзно - необходимо максимально автономное решение, не зависящее от хостинга, так что - увы и ах (squid был моей первой мыслёй, на что меня послали, со словами - надо самому думать как что оптимизировать; в общем, по-моему, правы...)


"Dynamicly composed pages, cache, fs"
Отправлено dev , 13-Дек-03 14:08 
>на что меня послали, со словами - надо самому думать как
>что оптимизировать; в общем, по-моему, правы...)

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


"Dynamicly composed pages, cache, fs"
Отправлено Александр , 13-Дек-03 18:44 
>>на что меня послали, со словами - надо самому думать как
>>что оптимизировать; в общем, по-моему, правы...)
>
>Кешинг - процес совсем не простой, там граблей много, поэтому лучше использовать
>готовый.
>Другое дело, что м.б. стоит оптимизировать создание страничек, ибо часто генерация на
>лету быстрее чтения с диска (естественно, зависит от многих факторов).
>А с самодельным кешем я бы не советовал связываться...

Чтобы генерация на лету была быстрее чтения с диска, думаю, должно использоваться не более 2 запросов к базе... А у меня значительно больше (например, вывод последних, скажем 25 новостей: 1 запрос на все новости + 25 -- на получение заголовков + 25 на получение их разделов + 25 на названия разделов... Многова-то получается... А если объединять всё это в одну таблицу, то тогда производительность бд страдать будет - колонок будет порядка 10 штук, обращение к которым будет далеко не всегда требовать всех столбцов...)


"Dynamicly composed pages, cache, fs"
Отправлено Александр , 13-Дек-03 15:20 
>>>Отлично, я убедился том, что сделано всё правильно =)
>>
>>А не проще поставить готовый кеш между клиентом и сервером? squid?
>
>Мы простых путей не ищем! =)
>А если серьёзно - необходимо максимально автономное решение, не зависящее от хостинга,
>так что - увы и ах (squid был моей первой мыслёй,
>на что меня послали, со словами - надо самому думать как
>что оптимизировать; в общем, по-моему, правы...)

Как, интересно можно закэшировать динамически создаваемые страницы при помощи squid? Если содержимое может меняться в любой момент или вообще постоянно?
Кстати, файловый кэш может оказаться даже быстрее shm-кэша.


"Dynamicly composed pages, cache, fs"
Отправлено dev , 13-Дек-03 15:52 
>Как, интересно можно закэшировать динамически создаваемые страницы при помощи squid?

есть у него accelerator режим

>Если содержимое
>может меняться в любой момент или вообще постоянно?

ну для начала привильно выставлять время жизни страничек



"Dynamicly composed pages, cache, fs"
Отправлено GliNT , 13-Дек-03 16:30 
>>Как, интересно можно закэшировать динамически создаваемые страницы при помощи squid?
>
>есть у него accelerator режим
>
>>Если содержимое
>>может меняться в любой момент или вообще постоянно?
>
>ну для начала привильно выставлять время жизни страничек

Если страница меняется ПОСТОЯННО, то время жизни у нее = 0.
Или если меняться она может в произвольный момент, тогда expire time не изместно совсем.
И зачем тогда кэш? ;)


"Dynamicly composed pages, cache, fs"
Отправлено dev , 13-Дек-03 17:07 
>Если страница меняется ПОСТОЯННО, то время жизни у нее = 0.
>Или если меняться она может в произвольный момент, тогда expire time не
>изместно совсем.
>И зачем тогда кэш? ;)

Ну это надо страшивать у автора топика.
Примеры, когда это сработает: новостные сайты - можно выставить время жизни 5 минут, к примеру. Если новость будет опублекована на пару минут позже - не проблема. Многие сайты анекдотов так делают: время жизни - сутки :) Обычно это реализуется простой статичной страничкой, обновляемой ежедневно, но суть та же.
Есть еще HEAD запрос. Но скрипт должен его понимать и знать, когда страничка устарела, а кеш его должен использовать. Как с этим у squid'а - не знаю, не пробовал.


"Dynamicly composed pages, cache, fs"
Отправлено Александр , 13-Дек-03 18:52 
>>Если страница меняется ПОСТОЯННО, то время жизни у нее = 0.
>>Или если меняться она может в произвольный момент, тогда expire time не
>>изместно совсем.
>>И зачем тогда кэш? ;)
>
>Ну это надо страшивать у автора топика.
>Примеры, когда это сработает: новостные сайты - можно выставить время жизни 5
>минут, к примеру. Если новость будет опублекована на пару минут позже
>- не проблема. Многие сайты анекдотов так делают: время жизни -
>сутки :) Обычно это реализуется простой статичной страничкой, обновляемой ежедневно, но
>суть та же.
>Есть еще HEAD запрос. Но скрипт должен его понимать и знать, когда
>страничка устарела, а кеш его должен использовать. Как с этим у
>squid'а - не знаю, не пробовал.

Как автор топика =)
на сайте есть: новости, каталог, библиотека и форум - вот на это всё кеш и хочется.
Идея такова: при первом обращении генериться содержимое; затем оно показывается посетителю и кешируется. Потом, будет всегда выдаваться оно, если не наступит одно из двух событий:
- будет поставлен флаг "грязного" кеша, который ставится при добавлении чего-либо в заданный раздел
- кеш будет удалён, по причине отсутвия обращений к нему.

Делать чат мне пока не нужно, так что и время жизни страницы равное нулю пока не нужно (а как я понимаю, более время жизни равное нулю нигде и не нужно).

А где можно почитать про HEAD запросы и их обработку?


"Dynamicly composed pages, cache, fs"
Отправлено GliNT , 13-Дек-03 20:06 
>Как автор топика =)
>на сайте есть: новости, каталог, библиотека и форум - вот на это
>всё кеш и хочется.
>Идея такова: при первом обращении генериться содержимое; затем оно показывается посетителю и
>кешируется. Потом, будет всегда выдаваться оно, если не наступит одно из
>двух событий:
>- будет поставлен флаг "грязного" кеша, который ставится при добавлении чего-либо в
>заданный раздел
>- кеш будет удалён, по причине отсутвия обращений к нему.
>
>Делать чат мне пока не нужно, так что и время жизни страницы
>равное нулю пока не нужно (а как я понимаю, более время
>жизни равное нулю нигде и не нужно).
>
>А где можно почитать про HEAD запросы и их обработку?

Разница, AFAIK, между HEAD и GET запросами это то, что при HEAD не выдается само тело ответа, все заголовки те же самые, как и при GET.
Так что не заморачивайся делая обработку разных методов запросов ;)
Но если захочешь почитать, поищи RFC2616, например на www.rfceditor.org

>- будет поставлен флаг "грязного" кеша, который ставится при добавлении чего-либо в
>заданный раздел
>- кеш будет удалён, по причине отсутвия обращений к нему.

подход верный

Кстати, вариант с 25 запросами для получения заголовков не слишком оптимальный. Советую найти вариант, чтобы делать это в 1 запрос. Будет раз в 20 быстрее ;)


"Dynamicly composed pages, cache, fs"
Отправлено Александр , 13-Дек-03 21:35 
>подход верный
>
>Кстати, вариант с 25 запросами для получения заголовков не слишком оптимальный. Советую
>найти вариант, чтобы делать это в 1 запрос. Будет раз в
>20 быстрее ;)

Оно, конечно, да... Да только архитектура пострадает... И как раз, чтобы читабельность (и, кстати, безопасность) кода не мешали производительности, я и завожу кеш...


"Dynamicly composed pages, cache, fs"
Отправлено Александр , 13-Дек-03 18:46 
>Кстати, файловый кэш может оказаться даже быстрее shm-кэша.

А можно разъяснить эту фразу? (Кто такой shm - Shared Memory Cache? как его делать, и почему он может быть быстрее)


"Dynamicly composed pages, cache, fs"
Отправлено GliNT , 13-Дек-03 20:01 
>>Кстати, файловый кэш может оказаться даже быстрее shm-кэша.
>
>А можно разъяснить эту фразу? (Кто такой shm - Shared Memory Cache?
>как его делать, и почему он может быть быстрее)

Это по способу хранения объектов в кэше.
shm - shared memory.
Странички из shm(SysV) - ~200мс,
из файлового кэша - ~20мс.

По крайней мере у меня было так, в чем дело я так и не понял. OS - FreeBSD, Perl 5.00503.
Кстати, еще одно большое преимущество файлового кэша против кэша в памяти - то, что после рестарта веб-сервера кэш остается ;)


"Dynamicly composed pages, cache, fs"
Отправлено Александр , 13-Дек-03 15:20 
>Только два последних вопроса:
>- можно ли написать что-то для собственного хешироани файлов (чтобы не зависеть
>от системы)? Изначально сайт написан на php, но если надо, могу
>написать на Си програмулину, которая будет заниматься только этим.

Есть готовые модули на PHP.
см. в PEAR: Cache, Cache::Lite

>- где копать про кеширование у 4-го mysql?
http://www.mysql.com/doc/en/Query_Cache.html


"Dynamicly composed pages, cache, fs"
Отправлено Александр , 13-Дек-03 19:00 
>Есть готовые модули на PHP.
>см. в PEAR: Cache, Cache::Lite
>
>>- где копать про кеширование у 4-го mysql?
>http://www.mysql.com/doc/en/Query_Cache.html

Спасибо.