HandyCache форум

Начатки этой функции уже есть - сохраняются признаки сжатия и редиректы.
Неплохо бы реализовать в полном объеме. Выбор, для каких URL сохранять - аналогично списку "Запись в кеш".
Наличие возможности хранения заголовков в кеше - хорошая база для других функций, например, для принятия решения об обновлении данных.

Вопрос, который много обсуждался, но так и не был решен - это где их хранить и как!

В общем, сначала обсуждаем тему: Индексирование кэша (http://handycache.ru/component/option,com_smf/Itemid,10/topic,76.0/)...

DenZzz
Хранить так же как сейчас хранятся редиректы - в ОТДЕЛЬНЫХ файлах (с именами на #h, например) в кеше. Ибо дополнительный индекс сейчас нужен лишь для уменьшения фрагментации и утилитам вроде историка, но никак не самому прокси!
Но ГДЕ и как хранить кеш - вопрос частный и к необходимости самого хранения заголовоков отношения не имеет.

Хранить заголовки в отдельных файлах-паспортах уже ни раз предлагалось и обсуждалось! Как и то, что по заголовкам можно организовать управлением загрузкой/кэшированием данных - см. тему: "Управление загрузкой по Заголовкам (http://handycache.ru/component/option,com_smf/Itemid,10/topic,122.msg882/#msg882)"!
(Кстати, зачем ты завел параллельную ветку?)

Противников хранения заголовков в отдельных файлах типа #h было, пожалуй, больше, чем сторонников! Основной аргумент против - это двоекратное увеличение количества файлов в кэше и, как следствие, двоекратное увеличение количества дисковых операций, что с учетом "медлительности" диска в итоге скажется на общей производительности! Как раз, чтобы разгрузить диск (и попутно, как показали опыты, процессор!) в свое время был реализован RAM-кэш!

Кроме того не стоит забывать, что двоекратное увеличение количества файлов + фрагментация на FAT32 файловых системах приведет к диким тормозам при работе с диском! А учитывая, что разместить кэш на NTFS с маленьким размером кластера не всегда есть возможность, то это весомый аргумент "против" хранения заголовков в отдельных парных файлах #h !


Видимо, ты плохо знаком с историей обсуждения! Автор Историка, rs, всегда был против индексов и за хранение заголовков в NTFS-потоках или парных файлах-паспортах...


То, что хорошо бы хранить заголовки - никто не против, в т.ч. и сам mai62 !!!
А вот вопрос: "Где их хранить и как?" - вызывал массу споров и до сих пор не решен!
Поэтому начинать надо именно с обсуждения универсального способа хранения метаданных, т.к. это основной камень преткновения!

DenZZZ
Вот именно, он был со мной согласен - самому HC (пока кеш хранится в папке) индекс не нужен!
Программа rs (Историк) создает индекс для своих нужд самостоятельно - ей он как раз необходим, но для совсем других целей (поиска по дате, содержимому и т.п.), которые для HC на данный момент не актуальны.
Держать кеш на FAT32 - мазохизм однако даже без всяких #h-файлов. ;)
Отлично, значит все с данной фичей согласны.
И окончательно решить его можно, только имея работающую реализацию. Ее-то мне и надо, хоть какую-то... Причем сейчас мне абсолютно все равно, как это будет в итоге реализовано! Реальную эффективность и удобство реализации покажет только тестирование на реальных задачах.
Она не параллельная, хотя и близкая. Фильтрация по входящим заголовкам может быть реализована и без хранения их в кеше - для кешированных файлов HC сейчас синтезирует заголовки самостоятельно.
Но хранение заголовков в кеше - функция сравнительно простая, ее можно реализовать и оттестировать ДО более сложных и мощных фич вроде фильтрации по заголовкам или использования для кеширования полей заголовка протокола HTTP 1.1.

Однако ж, многие держат! Например, носят кэш с собой на флэшке домой и на работу и указывают ее в качестве основного кэша в HC... А NTFS на флешку можно поставить только с помощью специальных "танцев с бубнами", причем это уменьшит скорость доступа к флешке и создаст дополнительные неудобства в ее использовании (права админа, безопасное отключение и т.п.)!

Да много всяких разных вариантов, когда нельзя поставить кэш на NTFS (старый комп, мало памяти, кэш на сервере без NTFS и т.д.)...

Кстати, а двоекратное увеличение количества дисковых операций от чтения/записи парных файлов #h , что с учетом "медлительности" диска в итоге скажется на общей производительности HC, не пугает? Как раз, чтобы разгрузить диск (и попутно, как показали опыты, процессор!) в свое время и был реализован RAM-кэш...


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

DenZZZ
Жестко... Флешка все-ж таки не HDD. И работа с кучей мелких файлов всегда будет ее слабым местом - там хоть весь кеш в БД размещай.
Заголовки - первый кандидат на попадание в RAM-кеш. Они ничем не хуже и не лучше обычной мелочи.
Теперь об удвоении - плоха та фича, которую нельзя отключить ;)
Поэтому в первом же посте я предложил
И держатели кешей на FAT-32 будут целы и NTFSники сыты.
Ну ты сравнил! Хранение заголовков в кеше и плагинный API!
Конкретная реализация второго на порядок сложнее и при проектировании и при написании.
Оно конечно хорошо бы модуль кеша отделить от всего остального - но мое предложение относится к одной из следующих версий, а не к 2.х.

Только не всегда верно она их синтезирует. Особенно mime-тип

Да. Картинки у меня однажды вылезли из кэша как текст :(
Слишком много метаданных запихано было в начале jpg.

Похоже, эту тему пора снова поднять.
Ибо случаи принятия картинки за текст раздражают весьма и весьма.
А также очень хочется нормальной докачки.

Есть предложение:
Для кеширования заголовков можно использовать БД SQLlite
http://www.sqlite.org/

В ней же можно хранить историю запросов

насколько я знаю активно используется в проектах mozilla

Единственный минус она написана на C.