форумы  помощь  поиск  регистрация  майллист  ВХОД  слежка

Вариант для распечатки		Архивированная нить - только для чтения!  Пред. тема | След. тема
Форумы WEB технологии (Public)
Изначальное сообщение		[Проследить за развитием треда]

"Dynamicly composed pages, cache, fs"
Сообщение от Александр on 11-Дек-03, 18:16  (MSK)
Народ, помогите, пожалуйста, разрешить следующую проблему: - хочется харнить кеш-копии сгенерированных страниц, и посчитанных данных - хочется добавлять, например, к новостям, картинки Соответственно и то и другое - на файловой системе. Внимание вопрос: как это сделать, так, чтобы файловая система не умерла (то есть запросы к ней не были слишком долгими)? Если просто создать, скажем директорию news, и в ней создавать директории по номеру новости, и складывать все аттачи в неё, то не начнуться ли проблемы, скажем на 10'000 новости (а их уже реально 5'000)? То же относится и к кешу... Только его можно переиодичски чистить, а вот чистить аттачи к новостям... - пользователи не поймут =) Единственное решение, которое мне удалось придумать, это ввести некоторый коэфициент деления - например, 400 - тогда аттачи к новостям будут сохраняться в примерно таком виде - /news/0-400/138/SomeAttach.jpg Кто что скажет? Заранее благодарен, /Александр.
	Рекомендовать в FAQ | Cообщить модератору | Наверх

Индекс форумов | Темы | Пред. тема | След. тема

Сообщения по теме

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

	2. "Dynamicly composed pages, cache, fs"
	Сообщение от Александр on 11-Дек-03, 21:44  (MSK)
	>Вообще-то специально для хранения данных и придумали базы данных. В твоем случае >она подходит как нельзя лучше. Аттачи лучше класть в разные директории, >если их много. Допустим создать 1000 директорий с 000 по 999 >и в них раскладывать аттачи. Вообще системам *nix пофигу, сколько файлов >у тебя в директории, просто чем их больше, тем дольше будет >поиск. Это проявляется где-то тысяч с 10 файлов(примерно). Спасибо за ответ. Только вот с базой данных - не совсем то, что надо. Задача - кешировать сгенерированые страницы, чтобы лишний раз не лезть в базу, и чтобы она не пухла как минимум вдвое + снизить время генерации, и хочется хранить кеш в файлах (например, наиболее популярные новости; старые - чистить, базируясь на времени последнего обращения). Кроме того, есть функции, которые в результате своей работы делают порядка 10 запросов к базе, да ещё и над ними работают - результат их работы также хочется складывать в кеш (получается немного "проапргрейденный" кеш запросов). Но вот если что у первых, что у вторых принцип работы одинаковый (имя файла/функции - директория; аргументы - имя файла и возможна периодическая зачистка), то вот с аттачами так не получится... Как я уже и писал ранее - есть определённый коэфиент деления (ты его задал в 1000), который снизит нагрузку на файловую систему, но и как ты сказал - скорость обращения всё равно будет падать, при возрастании количества директорий и файлов, а как раз этого и хочется избежать...
		Рекомендовать в FAQ | Cообщить модератору | Наверх

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

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

	5. "Dynamicly composed pages, cache, fs"
	Сообщение от dev on 12-Дек-03, 23:18  (MSK)
	>Отлично, я убедился том, что сделано всё правильно =) А не проще поставить готовый кеш между клиентом и сервером? squid?
		Рекомендовать в FAQ | Cообщить модератору | Наверх

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

	7. "Dynamicly composed pages, cache, fs"
	Сообщение от dev on 13-Дек-03, 14:08  (MSK)
	>на что меня послали, со словами - надо самому думать как >что оптимизировать; в общем, по-моему, правы...) Кешинг - процес совсем не простой, там граблей много, поэтому лучше использовать готовый. Другое дело, что м.б. стоит оптимизировать создание страничек, ибо часто генерация на лету быстрее чтения с диска (естественно, зависит от многих факторов). А с самодельным кешем я бы не советовал связываться...
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	13. "Dynamicly composed pages, cache, fs"
	Сообщение от Александр on 13-Дек-03, 18:44  (MSK)
	>>на что меня послали, со словами - надо самому думать как >>что оптимизировать; в общем, по-моему, правы...) > >Кешинг - процес совсем не простой, там граблей много, поэтому лучше использовать >готовый. >Другое дело, что м.б. стоит оптимизировать создание страничек, ибо часто генерация на >лету быстрее чтения с диска (естественно, зависит от многих факторов). >А с самодельным кешем я бы не советовал связываться... Чтобы генерация на лету была быстрее чтения с диска, думаю, должно использоваться не более 2 запросов к базе... А у меня значительно больше (например, вывод последних, скажем 25 новостей: 1 запрос на все новости + 25 -- на получение заголовков + 25 на получение их разделов + 25 на названия разделов... Многова-то получается... А если объединять всё это в одну таблицу, то тогда производительность бд страдать будет - колонок будет порядка 10 штук, обращение к которым будет далеко не всегда требовать всех столбцов...)
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	8. "Dynamicly composed pages, cache, fs"
	Сообщение от Александр on 13-Дек-03, 15:20  (MSK)
	>>>Отлично, я убедился том, что сделано всё правильно =) >> >>А не проще поставить готовый кеш между клиентом и сервером? squid? > >Мы простых путей не ищем! =) >А если серьёзно - необходимо максимально автономное решение, не зависящее от хостинга, >так что - увы и ах (squid был моей первой мыслёй, >на что меня послали, со словами - надо самому думать как >что оптимизировать; в общем, по-моему, правы...) Как, интересно можно закэшировать динамически создаваемые страницы при помощи squid? Если содержимое может меняться в любой момент или вообще постоянно? Кстати, файловый кэш может оказаться даже быстрее shm-кэша.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	10. "Dynamicly composed pages, cache, fs"
	Сообщение от dev on 13-Дек-03, 15:52  (MSK)
	>Как, интересно можно закэшировать динамически создаваемые страницы при помощи squid? есть у него accelerator режим >Если содержимое >может меняться в любой момент или вообще постоянно? ну для начала привильно выставлять время жизни страничек
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	11. "Dynamicly composed pages, cache, fs"
	Сообщение от GliNT on 13-Дек-03, 16:30  (MSK)
	>>Как, интересно можно закэшировать динамически создаваемые страницы при помощи squid? > >есть у него accelerator режим > >>Если содержимое >>может меняться в любой момент или вообще постоянно? > >ну для начала привильно выставлять время жизни страничек Если страница меняется ПОСТОЯННО, то время жизни у нее = 0. Или если меняться она может в произвольный момент, тогда expire time не изместно совсем. И зачем тогда кэш? ;)
		Рекомендовать в FAQ | Cообщить модератору | Наверх

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

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

	18. "Dynamicly composed pages, cache, fs"
	Сообщение от GliNT on 13-Дек-03, 20:06  (MSK)
	>Как автор топика =) >на сайте есть: новости, каталог, библиотека и форум - вот на это >всё кеш и хочется. >Идея такова: при первом обращении генериться содержимое; затем оно показывается посетителю и >кешируется. Потом, будет всегда выдаваться оно, если не наступит одно из >двух событий: >- будет поставлен флаг "грязного" кеша, который ставится при добавлении чего-либо в >заданный раздел >- кеш будет удалён, по причине отсутвия обращений к нему. > >Делать чат мне пока не нужно, так что и время жизни страницы >равное нулю пока не нужно (а как я понимаю, более время >жизни равное нулю нигде и не нужно). > >А где можно почитать про HEAD запросы и их обработку? Разница, AFAIK, между HEAD и GET запросами это то, что при HEAD не выдается само тело ответа, все заголовки те же самые, как и при GET. Так что не заморачивайся делая обработку разных методов запросов ;) Но если захочешь почитать, поищи RFC2616, например на www.rfceditor.org >- будет поставлен флаг "грязного" кеша, который ставится при добавлении чего-либо в >заданный раздел >- кеш будет удалён, по причине отсутвия обращений к нему. подход верный Кстати, вариант с 25 запросами для получения заголовков не слишком оптимальный. Советую найти вариант, чтобы делать это в 1 запрос. Будет раз в 20 быстрее ;)
		Рекомендовать в FAQ | Cообщить модератору | Наверх

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

	14. "Dynamicly composed pages, cache, fs"
	Сообщение от Александр on 13-Дек-03, 18:46  (MSK)
	>Кстати, файловый кэш может оказаться даже быстрее shm-кэша. А можно разъяснить эту фразу? (Кто такой shm - Shared Memory Cache? как его делать, и почему он может быть быстрее)
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	17. "Dynamicly composed pages, cache, fs"
	Сообщение от GliNT on 13-Дек-03, 20:01  (MSK)
	>>Кстати, файловый кэш может оказаться даже быстрее shm-кэша. > >А можно разъяснить эту фразу? (Кто такой shm - Shared Memory Cache? >как его делать, и почему он может быть быстрее) Это по способу хранения объектов в кэше. shm - shared memory. Странички из shm(SysV) - ~200мс, из файлового кэша - ~20мс. По крайней мере у меня было так, в чем дело я так и не понял. OS - FreeBSD, Perl 5.00503. Кстати, еще одно большое преимущество файлового кэша против кэша в памяти - то, что после рестарта веб-сервера кэш остается ;)
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	9. "Dynamicly composed pages, cache, fs"
	Сообщение от Александр on 13-Дек-03, 15:20  (MSK)
	>Только два последних вопроса: >- можно ли написать что-то для собственного хешироани файлов (чтобы не зависеть >от системы)? Изначально сайт написан на php, но если надо, могу >написать на Си програмулину, которая будет заниматься только этим. Есть готовые модули на PHP. см. в PEAR: Cache, Cache::Lite >- где копать про кеширование у 4-го mysql? http://www.mysql.com/doc/en/Query_Cache.html
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	16. "Dynamicly composed pages, cache, fs"
	Сообщение от Александр on 13-Дек-03, 19:00  (MSK)
	>Есть готовые модули на PHP. >см. в PEAR: Cache, Cache::Lite > >>- где копать про кеширование у 4-го mysql? >http://www.mysql.com/doc/en/Query_Cache.html Спасибо.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

Удалить

Индекс форумов | Темы | Пред. тема | След. тема

Пожалуйста, прежде чем написать сообщение, ознакомьтесь с данными рекомендациями.