HandyCache форум

Ты под индексом понимаешь базу, в которой хранятся все эти сведения?
Это же памяти много съест!
Надо использовать методы поисковиков. Когда индекс не содержит самих данных, но позволяет узнать где они лежат.
За основу можно взять исходные коды программы locate, которая портирована из unix и позволяет мгновенно искать файлы на диске по имени или другим аттрибутам.

И где они лежат, интересно? :)

И индекс наверно лучше делать в виде какого-нибудь Embedded-SQL, как например у историка.

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

Сергей


Не так уж и много! Зато это ускорит работу и уменьшит количество обращений к диску, который и без того работает медленно!
Кстати, кроме прочего, использование RAM-кэша уменьшает загрузку процессора!


HC всегда знает, где у него лежат файлы (данные)! Он их не ищет по всему диску, а проверяет конкретный путь! Поэтому метод поисковиков в HC не применим!

К тому же, в индексе будет храниться не так уж и много данных: URL, даты, Content-Type (где потребуется)...

DenZzz
RAM кэш фактически уже выполняет эту функцию. Нет смысла хранить в памяти список всех файлов кэша.
Конкретный путь мы сразу по URL узнать не в состоянии.
Алгоритм URL2File предполагает, как минимум, несколько обращений к диску для проверки существования файлов/каталогов.

Сергей


Согласен! Идея индексов кэша активно обсуждалась еще до появления RAM-кэша!

Сейчас индексы уже не так актуальны, но осталась проблема с очисткой кэша по датам доступа, которые могут сбиваться! Вот недавно опять всплыла эта тема (http://handycache.ru/component/option,com_smf/Itemid,10/topic,73.0/). Надо где-то хранить даты доступа, индекс бы подошел...

Еще надо хранить где-то "Content-Type" для неизвестных HC форматов...


Почему же? Преобразовали URL - получили точный путь к файлу - проверили на диске.
Иногда, конечно, еще вспомогательные файлы надо проверить (типа #m), но это уже частность...

А почему только для неизвестных? Можно и для всех. Тогда не надо будет проверять сигнатуру, да и правила на основе типа можно сделать...
Тем более что хранить стоит не саму строку - а только её номер в списке - т е 4 байта.

А тут кстати интересная возможность вырисовывается - уже загруженные файлы останутся доступны при изменении правил...
Да и преобразование имени в соответствии с новыми правилами можно сделать (отдельной программой)

DenZzz
Тем не менее, на мой взгляд, очень даже актуальны. Вот еще одна польза их применения.
Сейчас НС не может использовать заложенный в HTTP механизм времени устаревания (expiration). Сервер часто посылает в ответе в поле "Expires:" или "Cache-Control: max-age=" дату/время, до истечения которой файл точно изменяться не будет. До этого времени мы смело можем не обращаться к серверу невзирая на содержание списков "Только из кэша" и "Не обновлять", не проверять If-Modified-Since, а смело выдавать файл из кэша. Для этого нам надо сохранять указанное поле (max-age, а при его отсутствии Expires) в индексе.

Индексы это интересно, но как это все будет работать в том случае когда у кучи юзверей стоит HC с общим кеше на сервере? Как бы не получилось так, что при попытке записать индекс одним из юзверей файл окажеться занят другим ...

Так и не может получиться! Т.к. при правильной настройке писать в кэш может только один юзер, а все остальные только читают из него - у них общий кэш настроен в строке "Только для чтения"!
Если у вас в сети иначе, то конфликты неизбежны и без всяких индексов!

Для более-менее серьёзного кеша - с индексом нужно через БД работать, тогда и проблемы с доступом автоматом решатся

С учетом необходимости экономии памяти предлагаю рассмотреть вопрос создания двухуровневого индекса.
Уровень 1: индекс по всем хостам (грузится в память при запуске программы и постоянно находится там), хранится в корневой папке кэша. Включает следующие поля:
- имя (имена) хоста;
- IP-адрес(а) хоста (первые два пункта - то, что сейчас итак хранится в кэше DNS, так что кэш DNS при этом уйдет);
- дата последнего доступа к хосту (для предварительного отсева URL по критерию свежести и возможно для целей грубой автоматической очистки);
- если нужна какая-то реалтаймовая статистика в разрезе по сайтам, то данные этой статистики по конкретному хосту.
Если какого-то сайта нет в индексе, то уже на этом этапе мы принимаем решение об отсутствии файла в кэше.
Уровень 2: индекс по всем URL данного хоста, находится в корневой папке хоста. Здесь уже можно хранить все, что ни придумаем по конкретному URL. Подгружается в память по мере надобности; выгружается, например, по таймауту либо по принципу FIFO при превышении заранее заданного размера занимаемой RAM.

На примере собственного кэша (стоИт "писать в кэш все") пронаблюдал ориентировочный порядок цифр:
Кэш - 900 МБ.
Папок в корневой директории - 5 000 (число записей в индексе 1 уровня).
Файлов - 90 000.
"Среднее число" хостов на 1 МБ кэша - 5,5 (т.е. кэш объемом 10 ГБ будет содержать ~55 тыс. записей в индексе 1 уровня: по-моему, в достаточной степени немного).
Среднее число URL на хост - 18 (т.е. среднее количество записей в индексе 2 уровня. Немного, т.е. можно хранить много атрибутов, не особенно скупясь и беспокоясь о том, что при загрузке в память это сожрет все ресурсы).

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

Давайте обсудим...

Михаил
В теории это все и так более-менее ясно. Проблемы начинаются при попытке обдумать практическую сторону:

• в каком формате хранить эти индексные файлы?
• как синхронизировать индекс и фактический кэш: т.е. если запись в индексе есть, а в кэше хоста нет - и наоборот.
  

Если грубо, то одна запись минимум полкилобайта в лучшем случае, а то и больше - смотря как и в каком формате хранить. 30-50М - это достаточно много или достаточно НЕмного для хранения в RAM?

Rick
Почему полкило? Речь ведь об индексе 1 уровня, в каждой записи которого хранится существенно меньше - только то, что относимо к сайту в целом.
А в индексе 2 уровня 18 записей. И пусть они будут хоть по 10 килобайт каждая: 1. их мало. 2. этот индекс выгружается при необходимости.
Какие варианты рассматриваются?
Ты имеешь ввиду форс-мажор? Если да, то вижу так:
- если запись в индексе есть, а файла нет - качаем файл, корректируем попутно значения переменных типа "размер кэша";
- если есть файл, но он не обозначен в индексе, то мы это обнаружить вроде как не в состоянии.
Почему этот вопрос сопряжен с трудностями?
Если же ты имеешь ввиду не форс-мажор, а целенаправленную правку/удаление юзером файлов/каталогов, то предлагаю считать это все равно форс-мажором ;). Зачем ему туда влазить врукопашную?

Ну сам посчитай то, что ты предлагаешь:
Учитывая, что IP-адресов может быть несколько (как и имен на одном IP), имя домена до 254 символов, дата, статистика.

Какие предложишь - такие и рассмотрим.

Зачем его качать? Может он никому не нужен - за что и был удален пользователем из кэша.

Если искать файл в кэше независимо от наличия/отсутствия записи в индексе - можем.

Мне тоже хотелось бы так думать, да не получается: есть и охотники до ручных ковыряний, есть и те, кто переносят кэш с одного компа на другой и/или объединяют кэши простым копированием.

Не совсем так, например у меня:
Кеш - 13 Гб
сайтов в корне - 8500
файлов - 400.000

ЗЫ: Убрал нафиг все сайты с контентом менее 64К - кеш похудел на 100М, 5000 сайтов и 21000 файлов :)

Rick
Считаем:
- средняя длина имени хоста - 15,23 символа (посчитал на примере собственного кэша). Берем 16 байт;
- IP-адрес - 4 байта. Не знаю точно, но думаю, что 2 адреса - редкость. Но пусть соотношение 1/4. Тогда в среднем - 5 байт;
- дата - пусть 10 байт;
- статистика - пусть 20 байт (5 целых чисел).
Итого: в среднем 51 байт. Вполне!
А есть ли острая необходимость? Если да, можно, конечно, и поискать. Но чем обуcловлена надобность?
Могут ли охотники пересмотреть свои позиции, если им предложить взамен ускорение работы НС, статистику, автоматическую очистку кэша? Настолько ли неизменны их позиции? Это вообще изучалось? Если нет, давай обозначим этот вопрос здесь и сейчас.

Дем
Тогда у тебя индекс 1 уровня будет существенно меньшим (относительно размера кэша).
А я вот не чистил кэш уже сто лет. Могу рассматриваться как пессимистический прогноз ;).

Ты серьезно считаешь, что индекс 1 уровня, который будет постоянно находиться в памяти, способствует ее экономии?!


Кэш DNS содержит ограниченное число записей (у меня max=500), он автоматически чистится и обновляется - эх, не хотел бы я, чтобы в нем были все 55 000 записей! ;)


Во-первых, критерий свежести работает по дате модификации файла, а не по дате доступа к нему! Читать можно часто, а писать редко...
Во-вторых, у некоторых браузеров есть привычка последним загружать favicon.ico - вот тебе и обновление даты доступа к хосту, а все остальные файлы точно старее!

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


Что за статистика и с какой целью ее собирать?
Видимо, именно здесь должна будет храниться информация для автоматической очистки кэша... Вопрос только в том, как эти цифры собрать без лишних затрат ресурсов!


Ну, в общем, все что перечислено в первом посте этого топика, рожденное коллективным мозговым штурмом... :)


Принцип работы RAM-кэша описан в ФАКе (http://handycache.ru/component/option,com_simplefaq/task,display/Itemid,3/catid,1/#FAQ24)! Там же упомянуто то, что в нем хранится...

Опять же, у RAM-кэша свои критерии освобождения памяти - макс. размер RAM-кэша, а у индексов свои - "по таймауту либо по принципу FIFO при превышении заранее заданного размера занимаемой RAM" этими индексами. Может случиться так, что индекс пора выгружать, а в RAM еще его файлы остались! Синхронизировать их накладно!


М-да... Опять началось навязывание другим своих моделей поведения! Если бы этот вопрос звучал на ру-борде, тебя бы там просто "разорвали"! ;) Кто? Да тот же rs (автор Историка), unreal666 и другие любители поковыряться в кэше, переносить его части в архивах на флешке и чистить кэш сторонними программами (Историком и т.п.) мимо HC...

Хоть я всегда выступал в поддержку индексов, но, похоже, противника опять придется изображать мне за отсутствием их кворума на нашем форуме... :)

Смотря как хранить - в каком формате.

Сделай nslookup www.ya.ru - 2 IP адреса и один алиас.
А посмотри то же для www.microsoft.com - 7 (семь) IP адресов и три алиаса.

Но в общем-то, думаю, вообще нет необходимости хранить IP адреса. Заменить собой DNS кэш индекс не сможет - и не надо.

8

Именно тем, что в кэше может быть файл, о котором индекс "не в курсе".

В том и беда, что не хотят/не могут. И получается с одной стороны все хотят некий индекс, а с другой - всегда будет вероятность того, что его актуальность ничтожна. У меня пессимистичный взгляд на перспективу индекса.

И не только это. Кэш DNS нельзя заменить данными из индексного файла в принципе. В индексном файле данные только о том, что _хранится_ в кэше.

DenZzz
Имел ввиду ресурсов.
IP-адрес сервера нам нужен только после того как принято решение лезть в интернет. Слазив туда, мы должны проверить наличие файла в кэше. Значит, один хрен грузить индекс 2 уровня. Выходит, информацию об IP-адресе надо хранить в переменной в файле индекса 2 уровня и не засорять ими память вообще. Ну и пусть 55 тыс. IP хранится. Чего ж тут плохого? Долой их из индекса 1 уровня!
Я не путал дату доступа с датой модификации. Логика такая. Если запрашиваемый URL имеет критерий свежести, например, 1 день, а доступа к серверу не было год, то URL заведомо из кэша браться не будет (не надо даже проверять, есть ли он там). Если же запись в кэш для такого URL исключена, то дергать индекс второго уровня нам не нужно вообще.
Но теперь поразмыслив, прикинул, что это нелогичные, противоречащие друг другу условия - установить критерий свежести и при этом не писать в кэш. Это как раз то, за пресечение возможности пользователю сделать чего копья недавно с тобой ломал. Поэтому далее не обращаем внимания на этот "предварительный отсев по критерию свежести". Оставляем дату доступа только для нужд грубой автоматической очистки. Но очень уж она грубая - удалить весь сайт по дате последнего доступа. Хотя определенная логика есть. Будем думать, как сделать ее изящнее.
Скромно поправлю: в этом топике.  ::)
Статистика, отражающая осуществляемую НС экономию. С какой целью ее собирать - понятия не имею: просто не захотел вникать в эту тему до определения исхода голосования и "заложился на возможное будущее". ;)
Пока у меня нет определенности в вопросе,а надо ли вообще их синхронизировать. Чего-то голова кругом... Разберусь завтра.
Если ты писал это без учета моего последнего поста, то понятно. Если да, то где ты увидел навязывание? И еще. "Опять" - это про меня или про Ру-борд?  8)
Жизнь - театр, и люди в ней - актеры ;) Ты уж постарайся, чтоб rs и unreal666 не было за себя стыдно ;) Мож, узнают, посмеются дружно и беззлобно и дополнят собою кворум на оффоруме.

Rick
Пока имею мнение, что вполне сможет. Сохраняем IP-адрес в переменной в файле индекса 2 уровня. Как подгрузили индекс, считался и IP. Тот самый из семи, который сейчас сохраняется кэшем DNS.
Как он туда попал? Охотники постарались? ;)
Из-за того, что его сложнее реализовать, чем потоки NTFS, или почему-то еще?

Представь: после процедуры очистки файлового кэша папка хоста удалена, запись из индекса соответственно тоже. Или мы скачивали нечто не сохраняя на диск в кэш. В обоих случаях кэш DNS оказывается зависим от того что есть в файловом кэше, а это не верно.

Да.

Из-за того, что желание иметь актуальный индекс и желание иметь возможность ручной работы с кэшем мала-мала противоречат друг-другу.

Rick
Почему из этих двух желаний перетягивает второе?

Запретить ручную работу с кэшем нельзя - некоторым это действительно нужно. Например, некоторые синхронизируют кэш на работе и дома. Пренебречь их интересами нельзя - значит еще не сделанный индекс уже тянет за собой необходимость делать некие мастера синхронизации для слияния кэшей, мастер перестройки индекса (сканить весь кэш на предмет совпадения с индексом). Разработчики дополнений должны будут обучать свои дополнения работе с этим индексом или из самостоятельных приложений превращаться в несуществующие пока плагины, с тем, чтобы работу с индексом выполнял таки НС. Вот так: индекса еще нет, а проблем для того, чтобы он появился - хватает.

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

Oneri
Помимо "копеечной экономии" приобретаем дополнительную ясность структуры - вся информация, относящаяся к хосту, хранится в корневой папке хоста (в частности, в файле индекса) и не разбросана по разным файлам, которые приходится открывать. Есть еще мысль хранить там поддерживаемую сервером версию HTTP для выбора наиболее эффективного способа формирования запросов.
Rick
Всеми силами хочется уйти от этого варианта ;) Для того и думаю над отысканием эффективного алгоритма автоматической очистки.

Это неправильный подход! Зачем изначально писать в кэш то, что на 100% никогда больше не пригодится?!
Чтобы этим оправдать необходимость автоматической очистки?! Хвост вертит собакой!  :)

DenZzz
В предыдущем посте я сказал неверно: правильнее будет не "для того и думаю", а "в т.ч. для того и думаю".
Предлагаю на данном этапе от этой темы уклониться в целях продвижения основной темы топика :)

О.К. Но тогда следует также уклониться и от утверждений, что индекс заменит собой DNS-кэш, частично RAM-кэш и т.п. до тех пор пока не будут устранены ключевые противоречия! ;)


Версию HTTP в запросе браузер выбирает в соответствие со своими настройками! HC зачем нужны такие подробности?

DenZzz
ОК. С легкостью уклоняюсь. Только про RAM-кэш я имел ввиду другое - не заменить его индексом, а проанализировать, не вступит ли в противоречие/дублирование работа индекса как мы ее сейчас примерно мыслим с работой RAM-кэш. Если вступит - найти путь выхода из такого противоречия. И честно говоря, руки пока не дошли. Ну да ладно... Опустили пока эту тему.
Если браузер тупо запрашивает по HTTP 1.0 сайт, который двести раз качался по HTTP 1.1 (что есть факт), то это нехорошо. И если мы браузеру при этом верим, то не можем сразу же начать использовать, например, pipeline.

Ram Cache должен хранить  только данные ...  индексы тут не причем 
т.е. при запросе URL  процедура будет такова

1. обращаемся в индекс
2. если в индексе есть файл то лезем в рам кеш
3. если в рам кеше не нашлось то лезем в дисковый кеш

А если браузер сменился? 

Добавлено позже:
т.е. у меня на машине несколько браузеров один например Opera которая ходит по 1.1 а вторая FireFox у которого pipe line отключен в настройках

А что мы должны сделать? Ответить браузеру на его 1.0 нашим 1.1? ;)
Он может нас не понять от своей педантичности и правильно сделает! Проблема выбора протокола запроса должна решаться настройками самого браузера! Не забывай, что через HC может работать не только браузер, но любой другой клиент (приложение), которое может ничего не знать о 1.1 или не хотеть его использовать! А маскироваться эти приложения любят под известные браузеры (берут User-Agent из системных настроек)...

Oneri
Спасибо. Теперь видно, что пересекаться не будут. Прочел к тому же, наконец, то место в ФАКе про RAM-кэш. :)
Не понял, что будет "если он сменился"? Это ты о чем?

DenZzz
Именно так. Так ответит и сам сервер. Только вот браузер нигде не применит это знание и в другой раз снова запросит 1.0. А мы применим.

Уверен? Или речь идет о "неправильном" сервере? Боюсь, HTTP/1.0 клиент его не поймет... ;)

DenZzz
Мы просто передадим ответ сервера. И если он более поздней версии HTTP, "возьмем на заметку".
К примеру, handycache.ru - "правильный" сервер? ;)

Oneri
В голове давно сидит мысль (http://handycache.ru/component/option,com_smf/Itemid,10/topic,172.msg1507/#msg1507) о включении в программу возможности самостоятельно организовывать pipeline при закачке с серверов, поддерживающих 1.1. Без оглядки на браузер.

Не отвлекаемся от темы.

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

Что хранить в индексе.
По-моему, необходимо сохранять также значение поля Content-Encoding: в тех случаях, когда оно есть в ответе. Тогда сможем кэшировать Gzip-ованный и т.п. контент - т.е. громадный класс файлов, который сейчас, если я правильно понимаю, мы кэшировать не в состоянии.

Вот так новости! :o Это почему же?! 8)

NothingAnother
Тогда объясни, плиз, как это делает НС. Я просто не в курсе. По сигнатурам распознает?

Что значит "как"? ??? В каком виде получил контент из сокета - так и положил в кэш, без всяких трансформаций. Может, ты путаешь с HTTPS?  ::)

NothingAnother
Что НС отвечает клиенту, когда передает этот файл из кэша? Формирует ли поле Content-Encoding?

Если в ответе сервера это поле есть - HC его от браузера не "прячет" ;)

Вопрос-то был про то, когда НС достает файл из кэша, а не получает его с сервера   ???

В конец файла дописывается что-то вроде сигнатуры с инфой о кодировании, соотв. браузеру эта инфа и передаётся в поле Content-Encoding. А то, что место этой инфе - в индексе (при наличии оного) - факт!

И действительно, дописывает! Не знал! Спасибо. И Content-Type, и Content-Encoding. Обе в индекс надо будет пихать.
М-да... А вот собственно откуда возникло первоначальное подозрение о некэшировании gzip-контента: (http://handycache.ru/component/option,com_smf/Itemid,10/topic,253.msg2113/#msg2113)

Зачем хранить лишнюю инфу в индексе?

В первом посте этой темы речь шла только о "Content-Type" для неизвестных HC форматов!

Заголовки GZIP дописываются в конец файла, HTML - в теги, картинки распознаются по сигнатурам! Лично я не помню, когда браузер не смог правильно отобразить файл из кэша HC !

DenZzz
Мне кажется, она вовсе не лишняя в случае именно gzip. Чем же лучше писать что-то в тело ответа? Другим ПО такой файл может и не разжаться как следует либо вызвать еще какую ошибку. Да и в индекс эта инфа логичней впишется.
Можешь подробно рассказать, что именно и в каких случаях дописывает НС в HTML?

Этот файл разжимается как обычный архив любым архиватором!


В HTML дописывается тэг: <meta http-equiv=... > с Content-Type и кодировкой страницы, если его там не было. Например:

DenZzz
Все равно некультурно как-то. Тело ответа портим несвойственной ему инфой. А для индекса пары байт жалеем. Другое дело, когда метаданные хранить больше негде - тогда изощряться приходится. А тут-то чего огород городить? Или форматом gzip специально усмотрена возможность добавления в файл чего-угодно? Если так - то согласиться можно.
Спасибо, буду знать. Вот здесь все красиво - запись как раз "родная" добавляется.

Заголовки GZIP дописываются в конец файла делая архив невалидным - а в ряде случаев вообще не в конец, а вместо содержимого, картинки распознаются по сигнатурам! далеко не все - только основные. Даже флеш не распознаётся.
И ещё - как ты собираешься отличить index.php который text/html от style.php который text/css?

Побаловался тут с Offline Explorer. Многие функции у него дублируют возможности HC фактически. Даже может работать как прокси для автономного просмотра скачанных данных. SIDы удаляет. Переадресация есть...
IMHO стоит некоторые идеи перенять у него.
Например, заголовки сохраняются в файл Descr.WD3. Такой файл лежит в корне каждой папки.

Страницы с большими картинками даже проще загрузить через OE а потом скопировать пропавшие из-за отсутствия докачки файлы в кэш HC.

Примеры таких URL можно?


Опять же, приведи примеры URL картинок, что не распознаются!
Можно добавить распознание и их сигнатур...


В index.php, который text/html, по заголовку <meta http-equiv=... > ! А с распознанием text/css у тебя есть какие проблемы?
Давай примеры сайтов, где из кэша что-то не так отображается!


И вообще, ты выборочно выдернул кусок текста из ответа на реплику:


А я ответил, что мы и сейчас в состоянии кэшировать "громадный класс файлов" и что не надо сохранять "Content-Type" для известных HC форматов!

Для неизвестных пока форматов можно либо сохранять "Content-Type", либо попытаться добавить их распознание по сигнатурам!

Невалидным - собственно любой, стандарт gzip не предусматривает такую дозапись.
А "вместо" - это просто сбой при записи какой-то. периодически происходит, независимо от урла. А при следующей загрузке - всё ОК. А почему программа считает длину данных равной нулю - ХЗ.
Что распознаётся по сигнатурам, а что нет - это автора спрашивать надо. И для тех файлов, которые распознаются - действительно в базу писать лишнего не надо. Хотя, опять же - неизвестно что проще - взять значение из базы или сигнатуру анализировать.

Предлагаю следующую общую структуру файла индекса, лежащего в корневой папке каждого хоста:
1. Заголовок (1 Б):
  - номер версии (для возможности адаптации под последующие изменения структуры индексного файла) - 1 Б
2. Данные по хосту (~ 17 - 34 Б):
  - имя - ~ 17 Б (взята средняя длина имени хоста по собственному кэшу)
  - ? размер папки в кэше (для целей реалтаймового подсчета размера кэша) - 4 Б (размер папки до 32 ГБ)
  - версия HTTP (для учета в случае возможной оптимизации запросов) - 1 Б
  - IP-адрес (для целей кэширования DNS) - 4 Б
  - время последнего обновления IP-адреса (для кэширования DNS) - 8 Б
3. Метаданные по файлам хоста (~ до 300 Б / файл):
  - имя без имени хоста - до 200 Б
  - код ответа сервера (для кэширования ответов 3xx и 4xx) - 1 Б
  - дата последнего доступа (для автоматической очистки кэша) - 8 Б
  - Last-Modified (для формирования If-Modified-Since) - 8 Б
  - Date (для проверки критерия свежести и предугадывания (http://handycache.ru/component/option,com_smf/Itemid,10/topic,205.msg1714/#msg1714)) - 8 Б
  - Expiration time - 8 Б
  - Content-Type, если формат НС не распознает самостоятельно либо распознает, но результат не совпадает с полем ответа. Еще лучше, имхо, сохранять все и исключить из НС код распознавания - ? Б
  - Content-Encoding, если кодировку НС не распознает самостоятельно либо распознает, но результат не совпадает с полем ответа. Опять же, лучше, имхо, сохранять все и исключить из НС код распознавания - ? Б
  - Cache-Control: no-cache (вместе с Pragma: no-cache), must-revalidate, мож еще какие директивы управления кэшем (для опционального обеспечения стандартного /как велит rfc2616/ поведения НС при желании пользователя) - 1 Б

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

В процессе нахождения файла индекса в памяти к данным блока 3 можно добавлять тело файла (в случаях, когда сейчас файл считывается в RAM-кэш). Таким образом, индекс, на мой взгляд, способен заменить и DNS, и RAM-кэши.
Отдельно по поводу полноценности замены DNS-кэша. Если мы ни один файл из хоста не пишем в кэш или удаляем всю папку хоста из кэша, то отказываемся от экономии и, вероятно, не планируем туда возвращаться. Зачем тогда держать запись DNS для такого хоста? По-моему, хранение DNS в индексе все-таки оправдано. Как минимум тем, что все рядом, а также не надо хранить в памяти параллельную структуру с повторением в ней имен хостов.
Еще вопрос - в качестве имени хоста и файла хранить:
  - имя до преобразования URL2File?
  - преобразованное имя?
  - то и другое?

К блоку 3 необходимо также добавить:
  - Location (для кэширования ответов 3хх) - ? Б

Отказ от записи файлов хоста в кэш, вовсе не означает отказ от захода на сайт!
Например, когда нам важна постоянная актуальность данных с сайта, мы их в кэш не пишем.
Или, еще пример, в файлообменники мы заходим часто, но в кэш также ничего не пишем!

Избавиться от DNS-кэша, не получится еще и потому, что разные хосты могут с помощью "Преобразования URL" писаться в одну папку кэша!
Возникнет путаница в блоке 2, т.к. придется одновременно хранить сразу несколько имен хостов, IP, дат, версий HTTP и т.п. в одном индексе!
А в случае изменения правил в "Преобразовании URL" данные DNS могут быть частично утеряны или перепутаны!


Преобразованное имя хоста можно не хранить вообще, а брать его из пути к файлу индекса при его открытии. Заодно упрощаем ручное переименование папки, если поменяли правила в "Преобразовании URL".

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

Преобразованное имя файла без хоста хранить желательно, чтобы лишний раз не заниматься преобразованиями. Да и в случае добавления новых правил в "Преобразование URL" старые файлы останутся доступны...

Вот именно, что ТОЛЬКО ИХ. Но пишем в кэш css этого сайта, скрипты, картинки, favicon.ico. Т.е. папка в кэше создается все равно.
И там, имхо, пишем файлы тех же типов.
Мне кажется, что это скорее очень редкие исключения из общего правила. Если это так, то для такого исключения папку в корневом каталоге кэша можно создать только ради единственного файла индекса с записью IP-адреса.
Да, есть такая проблема. Тогда приходит мысль, что индекс надо хранить в папке корневого каталога кэша, соответствующей оригинальному (не преобразованному списком "П") имени хоста. В блоке 3 хранить исходный URL без имени хоста, не обработанный списком "П".

Вовсе не обязательно писать что-то в кэш! Если я веб-мастер, то мне вообще не надо что-то кэшировать на моем сайте, когда там идут работы!


А какой смысл в таком случае заменять существующий и отлично работающий DNS-кэш каким-то суррогатным отдельным индексом?!

Вот это и есть очень редкое исключение. Для него будет создан отдельный индексный файл.
На мой взгляд, больший, чем повторно хранить в отдельной структуре памяти тьму имен хостов для "отлично работающего DNS-кэша" (и при этом не знать, сработает ли очередное или нет, т.к. оно не попало в N избранных), когда это все уже и так есть в памяти у "какого-то суррогатного отдельного индекса" (и мы уверены на 100%, что запомненный IP будет выдан из кэша в период TTL) и выгружается вместе с ним по мере необходимости?
Индекс развязывает нам руки в плане возможности сделать DNS-кэш глобальным, а не на фиксированные N хостов.
А эти мои слова:
безотносительны к вопросу хранения в индексе IP-адресов. Одно предлагается независимо от другого. В моей цитате имеется в виду, что индекс с метаданными файла не обязательно будет лежать в одной папке с файлом.

Так можно все окончательно запутать! Удалив случайно одну полупустую папку во время чистки кэша, теряем весь индекс по другой!

А как быть пользователям, которые переключаются между 2 наборами кэшей? Где им искать свои DNS ?

Да и вообще, большой гвоздь в крышку индексов - это работа нескольких пользователей с одним общим кэшем на сервере в качестве "Основного", т.е. когда сразу несколько пользователей одновременно пишут в общий кэш файлы в одинаковые папки!
Хоть так и не рекомендуется работать, однако часто появляются посты о такой настройке HC...

В этом случае постоянная рассинхронизация индексов с кэшем просто неизбежна!

Имхо, напротив, мы вносим какой-то порядок в хаос, наводимый списком "Преборазование URL". Индекс будет храниться в папке с названием, соответствующим истинному названию сайта, даже если файл находится в совершенно другом месте. При изменении правила списка "Преобразование URL" метаданные из индекса продолжают как ни в чем ни бывало использоваться.
Про случайное удаление полупустой папки - это несерьезно. Случайно удалить можно все, в т.ч. программу, Windows и т.п. Удалили папку - лишились куска кэша при любом раскладе.
Это как? Поясни, плиз, цель переключений.
Почему ты думаешь, что синхронизации в этом случае добиться невозможно? На первый взгляд, не вижу непреодолимых сложностей. Что ты имеешь ввиду?

В настройках "Кэш / Каталог" видишь 2 набора кэшей? Не думал, зачем это? Прочти в Документации...


Потому что разные пользователи со своими копиями HC вполне вероятно могут зайти одновременно на один сайт - скажем, на наш. Каждый из них загрузит в память индекс нашего хоста и будет с ним работать независимо, а ходить они будут по разным страницам форума. В результате в кэше останется лежать индекс только того, кто выгрузит его из памяти и сохранит на диск последним! А где был первый и какие файлы с метаданными он в кэш положил, мы уже никогда не узнаем!
Можно, конечно, попробовать сделать синхронизацию индексов, если его первоначальная дата изменилась, но это лишние затраты ресурсов...

пролистал тему... как же усложнилась идея индексов... :)

Михаил
Если в под "имя без имени хоста" подразумевается URL без http://хост/, то замечу, что в стандарте длина URL вообще никак не ограничена (так и написано). А вот длина строк в различных средах ограничивается в 32768 символов. Это число можно считать теоретическим пределом (ужас). Из реальных URL попадались длиной около 2000 символов.

IMHO, в принципе поддержку индексов можно прикрутить и отлаживать через плагин (тут пока облом). Как я понимаю, индекс служит для сохранения доп. информации и не влияет на структуру кеша. Нужны навороты, ставишь плагин индекса, нет - не ставишь :)

Хорошо, что не все URL-ы такие :) Сложные были бы времена.
Индексы дают нам не только и не столько ускорение обработки запросов. Речь о том, что идея накопления метаданных не идет сама по себе. В привязке к ней идут такие существенные нововведения в программу как автоматическая очистка кэша, использование механизма времени устаревания HTTP (Expiration), осуществление предсказаний свежести файлов и др. Отказываться от всего этого путем неиспользования плагина, думаю, не захочется никому. Поэтому, имхо, лучше налечь дружно и "добить" тему хранилища метаданных как базовую для ряда других и обязательную для реализации в последующих версиях НС.

DenZzz
А где они ищут свои файлы? Там же искать и свои DNS!
Это вряд ли! Индекс будет сидеть в памяти сервера.

С легкостью откажусь от первого и последнего "существенного нововведения"! ;D Подробные аргументы уже приводил в соответствующих темах!
Но тем не менее, универсальное хранилище метаданных может пригодиться для разных целей...


Файлы они ищут то в одном кэше, то в другом! А зачем им одинаковые DNS в разных кэшах? Вероятно, им придется после переключения кэша снова запрашивать и обновлять DNS, т.к. обновленные IP были сохранены недавно, но в другом кэше, а в этом их нет!


Какого сервера? У каждого из пользователей запущена своя локальная копия HC, настроенная на общий кэш на сервере! Сразу несколько копий HC будут одновременно работать с индексами и писать файлы в общий кэш!

Вот видишь, и ты согласился с моим тезисом, что отказываться от ВСЕГО не захочется, видимо, никому ;) Тебе, думаю, также известен один "чрезвычайно существенный" список с неизменным правилом ".", который станет мне абсолютно бесполезен с введением автоматической очистки кэша. ;D Так что давай работать над индексом дальше ;)
А где ж мне искать DNS, если я свой кэш (пускай один из наборов) поместил на флэшку и воткнул эту флэшку в другой комп?

Такой режим потребует отказа каждого пользователя от своего видения структуры кэша и собственных принципов преобразования URL в имя файла. Другими словами, могут конфликтовать между собой списки "П" пользователей. Для выхода из ситуации пользователям придется, имхо, пользоваться одним списком "П" на всех. Как это хочешь организовывать, если НС на сервере не запускается?

Можно запретить пользователю запись в URLToCache.lst средствами Windows или скриптом копировать этот список с сервера перед запуском HC и т.д.
Собственно, никакой катастрофы от того, что пользователь добавит какие-то свои правила в "П" (конечно, в разумных пределах), не произойдет - просто он будет писать свои сайты/файлы в указанное им место, другие будут писать в другое. Вероятность, что они будут писать совершенно разные файлы по полностью совпадающему пути, крайне низка! Конфликт маловероятен...

Не отвлекайся от темы - как быть с индексом в этом случае?
Как быть с индексом в случае ручной правки кэша?
Вон в другой теме (http://handycache.ru/component/option,com_smf/Itemid,10/topic,78.msg3211/#msg3211) под это дело уже сортировку папок в кэше придумали...

Преимущества индексов, не совместимые, на мой взгляд, с правкой кэша вручную:
  - проверка наличия файла в кэше без обращения к файловой системе;
  - проверка свежести файла без обращения к файловой системе;
  - RAM-кэш (хоть он сейчас прямо и не относится к индексам, но из "той же серии" и уже сейчас несовместим с ручной правкой кэша);
  - подсчет в реалтайме текущего размера кэша (от него могут зависеть затратность осуществления реалтаймовой статистики и автоматической очистки кэша).
Как при введении индексов учитывать правку пользователем кэша вручную?
Предлагаю два варианта:
1. Позиционировать кэш НС как не подлежащий правке вручную (только чтение и полное копирование). При этом все преимущества индексов работают в полном объеме.
2. Сделать опцию "Разрешить ручную правку кэша", действием которой будет отмена перечисленных выше преимуществ (другими словами, при включенной опции НС будет работать медленнее, чем при выключенной, будет чаще грузить диск).  Указанные преимущества индексов работают только при выключенной опции. Приводить же индексы в соответствие после рукопашных действий (если будет желание уйти от ручной правки кэша) можно будет нажатием специальной кнопки "Восстановление индексов" (этот процесс будет разовым, однако достаточно длительным и затратным).

В ручной правке вся фишка программы. Если тебе это не нравится - ставь Squid. Там индекс есть.

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

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

а почему контент тайп хранить только для неизвестных типов? А если какой-то извращуга передаст .gif с контенттайпом текст? Мало ли какие извращенцы встречаются. Может тогда для всех хранить?

На мой взгляд, да, для всех. Но не из страха перед "извращугой", который к тому же еще и "передаст" ;), а для того, чтоб в будущем научить НС кэшировать данные по их типу безотносительно к URL (это будет Content-Type из ответа сервера или самостоятельно определенный по сигнатурам тип данных - не суть важно). Тогда мы смело сможем кэшировать рисунки с неочевидными URL, как например, аватары на этом форуме - http://handycache.ru/forum/index.php?action=dlattach;attach=62;type=avatar

Nike
Михаил

А с чего вы взяли, что HC сейчас определяет типы файлов по их URL ?  ;)
Вы ошибаетесь! HC определяет известные ему типы файлов по сигнатурам...



Мы и сейчас можем смело кэшировать и читать из кэша аватары на этом форуме! Для этого в список "Не обновлять" надо всего лишь добавить одно правило:
#5#~#True#~#handycache\.ru/forum/index.php\?.*(avatar|image)$#~##~##~#

Об этом и речи не было. Это как раз понятно. Речь о другом. Хорошо бы дать пользователю возможность использовать не только URL, а и тип данных, указанный в Content-Type ответа сервера и/или определенный НС самостоятельно по сигнатуре, для задания правил кэширования.
Несомненно. И такое правило давно стоит и работает. Но это только на данном форуме. Речь же идет об универсальности. Ты можешь сейчас, к примеру, задать правило: Не обновлять везде и всегда контент типа "рисунки"? Нет. Любой рисунок с нестандартным URL останется неохваченным.

В правилах мы анализируем URL запроса.
Content-Type содержится в ответе сервера.
Чтобы получить ответ, надо, как минимум, послать запрос.
Значит, в списке Не обновлять мы не можем анализировать Content-Type.

Еще вариант - когда файл уже есть в кэше - сохранять Content-Type в индексе или вытаскивать на лету по сигнатурам. В списки Не обновлять и Только из кеша надо придумать синтаксис для таких правил.

Михаил
Сергей

 :stopoff:

Управление загрузкой по заголовкам обсуждается в отдельной теме (http://handycache.ru/component/option,com_smf/Itemid,10/topic,122.msg882/#msg882)!
И реализовывать анализ заголовков, ИМХО, лучше отдельным списком и безотносительно к наличию/отсутствию индексов!

Речь о необходимости хранить в индексе тип данных. И не обязательно из заголовка, можно и самостоятельно определенный по сигнатуре.

Кроме индекса, есть еще несколько вариантов, где можно взять/хранить "Content-Type" для анализа и вовсе необязательно хранить их где-то отдельно для абсолютно всех файлов в кэше!

Да где ты такие цитаты берешь: "для абсолютно всех файлов в кэше"?! Об этом речи нет. Предлагается иметь в индексе поле для сохранения информации о типе данных в необходимых нам случаях (тип данных может быть любым независимо от умения распознавать его НС по сигнатурам). Необходимо сохранить - заполняем поле, нет необходимости - нет поля.
Почти каждое планируемое поле в конкретной записи индекса может быть, может отсутствовать. К примеру, нет необходимости хранить "Location" в конкретной записи индекса - не храним. Так же и с типом данных.
Ладно... Проехали.

Здесь:  :rtfm:

Ладно, проехали - "для всех" не храним, а только "в необходимых нам случаях"...

DenZzz
Речь шла не о всех файлах в кэше, а о всех типах данных ;)

Но я о другом. Навеянная недавними постами по организации структуры кэша в целях упрощения работы с ним вручную, пришла мысль хранить файлы индексов не в каталогах с файлами кэша, а в отдельном. Например, каталог "Cache" будет состоять из "Files" и "Metadata". Тогда индексы не будут мешаться и мозолить глаза любителям ручной правки в кэше. Правда, обидно, что никто до сих пор не обозначил конкретные случаи, цели и преимущества ручной правки кэша. Если кто может, дайте, плиз, такую информацию.

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

Предложенное выше (http://handycache.ru/component/option,com_smf/Itemid,10/topic,76.msg3247/#msg3247) (п.2), имхо, решает проблему синхронизации. Для тех, кому актуально править кэш вручную, все остается как есть (обращение к диску). Те, у кого опция отключена, будут использовать возможности индексов на полную катушку. Выиграют и те, и другие.

PS 1. Как предлагаешь ты, проблема синхронизации ведь все равно остается.
    2. Она есть уже и сейчас с RAM-кэшем.

Уже озвучил свое мнение выше (http://handycache.ru/component/option,com_smf/Itemid,10/topic,76.msg3341/#msg3341) и оно частично совпадает с твоим п.2 (http://handycache.ru/component/option,com_smf/Itemid,10/topic,76.msg3247/#msg3247), но отличие в том, что этот вариант я вижу как базовое и единственное компромиссное решение для сглаживания последствий рассинхронизации индекса в результате ручной правки кэша, переноса/слияния кэшей, системных сбоев, ошибок HC и т.д.
В этом случае рассинхронизация возможна, но не так критична, т.к. мы изначально не собираемся хранить в индексе данные обо всех файлах в кэше и проверять их наличие, даты и т.п. только по индексу.


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

DenZzz
Тогда предлагаю перейти (http://handycache.ru/component/option,com_smf/Itemid,10/topic,381.msg3351/#msg3351) от изложения абстрактной необходимости ручной правки кэша к описанию реального наполнения этой задачи. Мне, к примеру, видится здесь много неясных вопросов.

А что делать? Сейчас мы без этих данных живём ведь как-то?

интересно-можно ли сохранить-записать кеш HC на compact disk (на всякий случай) :) ,а потом использовать его (к примеру через месяц) или кеш устареет?

Можно. Устареет или нет - можешь сам настроить с помощью "критериев свежести" в списке "Не обновлять"! Если контент на сайте статический (картинки и т.п.), то он долго не устареет...

тема кажется чуть ли не главной для далтьнейшего прогресса handycash в области кэширования. она так и умерла тогда? в todo этого не вижу

Есть разные мнения на этот счет (см. выше)...


Плохо смотрел!

ни одного мнения за точ что это понизит качество кэширования не вижу. абсолютно все в поддержку того что эффективность увеличится. прозябает просто предложение тобой же кстати и инициированое уж не знаю почему нельзя делать его опциональное. как имя и тип файла узнавать как докачивать, как узнавать один ресурс в различной кодировке, сжатии, на разных языках как использовать заголовки кэширования http. длеать то что другие кэши от рождения умеют и должны делать?
здесь кажется недоработка программы. в основном своем деле кэшировании.

интересно какие нибудь работы ведутся по этой теме или только теоретические споры в этой ветке?

Не ведутся, на эту тему сейчас нет времени.

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

Служба индексирования Windows заточена под поиск текста внутри файлов. А HC нужен индекс для хранения заголовков ответов сервера и прочих атрибутов файлов.

То есть доступ к файлам она не ускоряет?
Жаль :(
А ведь по идее НТФС - это  БД.
Странно, почему к ней нельзя индексы прикручивать?..

Индексы у неё есть, но не те, которые нужны для HC

Так вот. Суть заключается в том, что HandyCache создаёт "Журнал" файлов которые он кеширует. Тем самым при запросе к новым сайтам он не будет рыться в кеше, и будет сразу знать, что файлов от этого сайта там нет. Ну а также, журнал разумеется должен загружаться в ОЗУ. Если и журналировать размеры файла и т.п. то тогда расширения такие как A-Size могли бы работать существенно быстрее, и сама работа кеша бы ускорялась.

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