» HandyCache ( Часть 4 )

forever
Цитата:

лишь хранящие кэш только на локальном диске, только на NTFS и неиспользующие антивирус Касперского

Ух ты, сколько ограничений!.. После такого отсева, походу останется 1 (максимум 1.5) юзера (ну а куда попрёшь против статистики, представленной forever'ом) Вот только насчёт последнего пункта скромное уточнение: технология iStreams затыкается снятием одной гульки...
Если снова захочется ответить - welcome to PM, флуду здесь не место...

NothingAnother

Цитата:

Весь пафос forever'a (в данном контексте only ) сводится к мышлению маргинального люмпена - "если у меня нет - пусть и у него не будет"

Не согласен. Кому понравится программа, которая для использования каких-то функций требует если не установки другой оси, то смены файловой системы. Это можно было бы как-то оправдать отсутствием другого выхода. Но в данном случае это ведь не так. Я склонен согласиться с V0lt

Цитата:

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

Проблем особых тут не вижу, только надо придумать как быть при сливании двух кэшей.

Цитата:

А что насчёт head'еров?

Не понял.
DenZzz

Цитата:

в кэше файла нет - начали качать (узнали заголовок) - выяснилось, что он входит в "Только из кэша" или "Черный список" - остановили закачку - послали браузеру "404".

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

mai62

Цитата:

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

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

Зато сколько трафика будет сэкономлено, когда размер заблокированного "по типу" файла превышает 1-2 килобайта!

mai62
Цитата:

Цитата: А что насчёт header'ов?

Не понял

После того, как установила обновление почему-то вижу все баннеры. Что делать?

Blumella
Проверь, включен ли "Черный список" и есть ли в нем нужные правила. И еще, посмотри в Мониторе HC, какие правила у тебя срабатывают.

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

кроме того, нечаяннная, по разнообразным причинам, рассинхронизация общего файла индекса с содержимым кэша приведёт к потере ВСЕЙ информации индекса

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

т.е. тут д.б. реализована система: один файл кэша - один файл его паспорта (доп.информации)
реализовать два варианта (на выбор пользователя): 1) в ntfs-потоке и 2)в обычном парном файле (вероятно xml)

mai62
кстати, файлы кэша на флешке я ношу в rar-архиве - и если он позволяет хранить ntfs-потоки, всё просто отлично


Добавлено:
mai62
btw, ты говорил о плагинах - так вот для начала метод записи информации в паспорт можно вынести во внешнюю реализацию (вернее, даже две) - два отдельных исполняемых модуля - один для записи переданных ему сведений в поток файла кэша, а второй - запись в xml-файл

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


Добавлено:
NothingAnother
forever
можно долго не препираться

те кто на дух не переносят ntfs-потоки - пусть используют xml-паспорта, парные каждому файлу кэша

если ни то ни другое кому-то вообще не нужно - хранение паспортов такой пользователь вообще отключит

mai62
Я думаю, стоит заблокировать возможность упорядочения списков простым однократным кликом мыши по столбцу - слижком уж легко это случайно сделать (хотя бы промахнувшись) - и сразу теряется вся информация о приоритете правил списка! Это очень неприятно, особенно если их порядок фактически определяет результат. Да и просто привык уже к своему порядку, знаешь, где какое правило искать - а тут всё сбивается! Или можно сделать запрос подтверждения перед упорядочением списка. А вообще, лучше, чтобы это был пункт контекстного меню заголовка столбца.

И ещё, мне кажется, очень полезен запрос подтверждения перед удалением правила. А то по интуитивной привычке от Excel иногда хочешь удалить содержимое одной ячейки (например, Исключение), а удаляется вся строка, причём без предупреждения... Потом её не всегда бывает легко восстановить...

popkov
Поддерживаю оба пункта! Сам не раз на этом накалывался! Хорошо, что есть резервные копии списков. Записал в ToDo...

Цитата:

Проверь, включен ли "Черный список" и есть ли в нем нужные правила. И еще, посмотри в Мониторе HC, какие правила у тебя срабатывают.

Черный список включен, галочка есть. В мониторе срабатывают правила 1 и 2.

rs

Цитата:

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

ИМХО, лучше иметь один базовый универсальный метод, подходящий для всех файловых систем, которым будет заниматься сам автор - mai62. Так будет больше порядка и меньше багов!
А "добровольцы" пусть пишут плагины для записи этой инфы в альтернативные хранилища: NTFS-потоки, базы данных и т.д.

---

Blumella

Выложи где-нибудь из папки HC: все файлы .lst и HandyCache.ini. Надо смотреть, что за правила там есть и как настроен HC...

DenZzz

Цитата:

которым будет заниматься сам автор - mai62.

конечно лучше всё деражать в одних руках

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

Добавлено:
DenZzz

Цитата:

А "добровольцы" пусть пишут плагины для записи этой инфы в альтернативные хранилища: NTFS-потоки

ок
пусть только будет механизм

Ради эксперимента попробовал скопировать первые 282 папки из кэша размером 42,4 МБ (44 489 819 байт).
Копировал в Far 1.70 2087 с помощью плагина FileCopyEx 1.7 в nul устройство (\\.\nul\), с включенным параллельным копированием.
Создал три вирт. диска (все с кластером 512 байт) – NTFS (со сжатием), NTFS (без сжатия), FAT32 - на каждый скопировал выбранные папки.
Для каждого диска делал три серии копирования. После каждого копирования Far закрывал и выполнял высвобождение памяти с помощью RAM Optimizer (из Customizer XP). Системный кэш при этом уменьшался до 18-20 МБ, вместо 180-250 МБ при обычной работе.
Были получены следующие данные:
Время\ ФС NTFS без сжатия NTFS со сжатием FAT32

NothingAnother

Цитата:

После такого отсева, походу останется 1 (максимум 1.5) юзера (ну а куда попрёшь против статистики, представленной forever'ом)

Я представлял хоть какую-то статистику?


Цитата:

скромное уточнение: технология iStreams затыкается снятием одной гульки...

А FAT32 так же скромно конвертируется в NTFS, железо при необходимости скромно апгрейдируется, не знаю только как скромно поступить с хранением кэша не на локальном диске. Наверно нужно НС все-таки распрощаться с претензиями на обслуживание нескольких компов и позиционироваться исключительно как локальный прокси. Действительно, скромнее нужно быть.
Ты бы скромно поведал, что тебя заставляет так скромно цепляться за потоки - просто инерция или что-то более существенное?

rs

Цитата:

те кто на дух не переносят ntfs-потоки - пусть используют xml-паспорта, парные каждому файлу кэша

rs, твоя позиция меня удивляет. Т.е. ты согласен в Историке делать два способа реализации: с использованием потоков и без? Сделать один универсальный способ не по джидайским правилам?

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

forever
Цитата:

Будет ясность с данными - появится ясность и как и хранить

Без обсуждения? Ну, и откуда она появится? Следует ли это понимать, что истина тебе давно известна, но просто не пришло время её сообщить?

Цитата:

Я представлял хоть какую-то статистику?

Хм-м, не безнадёжно, прогресс! - начинаешь что-то понимать...

Цитата:

нужно НС все-таки распрощаться с претензиями на обслуживание нескольких компов и позиционироваться исключительно как локальный прокси

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

NothingAnother

Цитата:

Без обсуждения? Ну, и откуда она появится?

Не берись читать между строк - не умеешь. То тебе какая-то статистика мерещится, то отказ от обсуждений.


Цитата:

Следует ли это понимать, что истина тебе давно известна, но просто не пришло время её сообщить?

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


Цитата:

Повторно предлагаю воспользоваться ПМ (если только ты не тинейджер с маниакальным "моё слово - последнее!")

Какой-то детский сад на прогулке. Чтобы не было еще "повторов": мне нечего тебе писать в приват (а что в твоем представлении я тебе должен писать?).
Мне бы таки услышать про потоки... Какуюнить аргументацию в их пользу, а не демагогию. Почему-то ведь ты грудью встал на защиту потоков - еще б потрудился объяснить почему.


Цитата:

вынужден напомнить, что на этом форуме провоцирование участников на нарушение правил само является нарушением.

Какая прелесть. Вот прямо-таки вынужден?

forever

Цитата:

воя позиция меня удивляет. Т.е. ты согласен в Историке делать два способа реализации: с использованием потоков и без? Сделать один универсальный способ не по джидайским правилам?

почему удивляет?
да, согласен делать два. методов будет хоть и два, но протокол доступа к ним (имена и количество и состав параметров) будут идентичны - обычный полиморфизм в терминах ООП - мне даже нравится

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

при этом я уверен, что бОльшая часть пользователей выберет именно ntfs-потоки - маргинальных fat-поклонников с течением времени будет всё меньше и меньше

Цитата:

Мне бы таки услышать про потоки... Какуюнить аргументацию в их пользу, а не демагогию.

+ Чтение потока происходит быстрее, чем обработка индексного файла
+ Не захламляется кэш всякими индексными файлами

forever

Цитата:

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

сам всё перечислил - и говоришь "не понятно"

мне кажется - слова ради слов



Добавлено:
casm82

Цитата:

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

для far-а есть плагин, который позволяет просматривать ntsf-потоки файла


Добавлено:
unreal666

Цитата:

+ Чтение потока происходит быстрее, чем обработка индексного файла
+ Не захламляется кэш всякими индексными файлами

+ ГАРАНТИРОВАННАЯ нерассинхронизация файла кэша и его паспортных данных - доп. файл НИКОГДА не потеряется

rs

Цитата:

да, согласен делать два.

Хозяин - барин.


Цитата:

при этом я уверен, что бОльшая часть пользователей выберет именно ntfs-потоки

Не разделяю твоей уверенности. Не говорю, что ты ошибаешься - просто сомневаюсь.
У меня два компа, кэш на стационарном - значит ноут пролетает с потоками. На стационарном NTFS, но я юзаю KAV - опять пролет. Отключать iStream ради того, чтобы НС мог работать с потоками и получить тормоза у каспера - ни малейшего желания. Я такое уж исключение из правил?

unreal666

Цитата:

+ Чтение потока происходит быстрее, чем обработка индексного файла
+ Не захламляется кэш всякими индексными файлами

Спасибо, но все это убивается тремя словами: FAT, KAV и LAN. Тем интереснее мне услышать камрада NothingAnother'а - из-за чего столько слюны?

rs

Цитата:

сам всё перечислил - и говоришь "не понятно"

Не понятно. Это просто общие слова - никакой конкретики.

Добавлено:
Тут еще вспомнилось про хранящих кэш на виртуальных дисках...

casm82

Цитата:

Как оказалось, для моего случая, на малых файлах ntfs со сжатием выигрывает.

Было бы интересно детальнее в этом разобраться! Всё-таки актуальный вопрос, стоит ли использовать NTFS со сжатием для хранения кэша? Не приводит ли это к ещё большей фрагментации в процессе записи-перезаписи?

Цитата:

Копировал в Far 1.70 2087 с помощью плагина FileCopyEx 1.7 в nul устройство (\\.\nul\), с включенным параллельным копированием.
Создал три вирт. диска (все с кластером 512 байт) – NTFS (со сжатием), NTFS (без сжатия), FAT32 - на каждый скопировал выбранные папки.

Я так понял, что приведённые цифры - это время чтения файлов. А виртуальные диски как создавались?
Кстати, эффективность сжатия NTFS, насколько я понимаю, зависит от размера кластера?

forever

Цитата:

"Обычный полиморфизм" - это диаметрально наоборот.

нет
с точки зрения моего историка я буду вызывать, к примеру, метод ЧИТАТЬ_ПАСПОРТ - и в зависимости от контекста (ntfs или no-ntfs) будет вызываться та или иная реализация чтения - историку будет абсолютно безразлично, откуда на самом деле читаются данные


Цитата:

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

я же не сказал - что ВСЕ используют (будут использовать) ntfs-потоки, речь лишь о массовости тех и других пользователей
остальных пользователей я также безусловно принимаю во внимание

Цитата:

Я такое уж исключение из правил?

- не исключение, но менее массовое явление, imho


Цитата:

Спасибо, но все это убивается тремя словами: FAT, KAV и LAN.

LAN я бы отсюда исключил, а для FAT и KAV (и то не в любой кнофигурации) - полиморфная альтернатива - в чём здесь проблема?
для остальных - коих если не большинство, то уж немало - ничего не убивается

мы никого ничего не заставлем - каждый выберет себе полиморфную реализацию сохранения-чтения по вкусу


Цитата:

Не понятно. Это просто общие слова - никакой конкретики.

не знаю, о какой ещё конкретике речь, уж вроде я не раз говорил о своей колокольне - для каждого файла кэша нужно хранить его пользователя-владельца-загружальщика-из-нета - понятнтей уж некуда

Добавлено:
forever

Цитата:

Тут еще вспомнилось про хранящих кэш на виртуальных дисках...

и в чём проблема? если хочешь, концептуально для удобства можно полагать 1) ОСНОВНЫМ способом хранения доп.информации - обычный файл, а 2)оптимизированным, улучшенным - хранение в ntfs-потоках

rs
Я уж и фразу удалил про полиморфизм чтобы не спорить еще и об этом. Тем более коли я не прав.


Цитата:

- не исключение, но менее массовое явление, imho

Ну, то, что у меня одного собралось все три фактора (хорошо еще кэш не на виртуальном диске), конечно делает мой пример "менее массовым"...


Цитата:

LAN я бы отсюда исключил

Почему?


Цитата:

не знаю, о какой ещё конкретике речь, уж вроде я не раз говорил о своей колокольне - для каждого файла кэша нужно хранить его пользователя-владельца-загружальщика-из-нета - понятнтей уж некуда

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


Цитата:

и в чём проблема? если хочешь, концептуально для удобства можно полагать 1) ОСНОВНЫМ способом хранения доп.информации - обычный файл, а 2)оптимизированным, улучшенным - хранение в ntfs-потоках

Проблема? Если есть кто это будет делать - никаких проблем. Я ж сказал: хозяин - барин. Хочется сделать два разных метода - пожалуйста. Я за универсальные решения, если тебе нравятся "узко-специализированные" но ведущие к одному результату - дело вкуса наверное.

forever

Цитата:

Я за универсальные решения,

Универсальным это решение не является. На слабых компах такое решение может сильно тормозить комп.

unreal666

Цитата:

Универсальным это решение не является.

"Это решение" - это какое из двух?

forever

Цитата:

Ну, то, что у меня одного собралось все три фактора (хорошо еще кэш не на виртуальном диске), конечно делает мой пример "менее массовым"...

особенности моих машинок в некоторых моментах тоже далеки от среднестатистических, из чего я не делаю никаких выводов об их массовоти

Цитата:

> LAN я бы отсюда исключил
Почему?

я наверное пропустил - а чем собственно LAN мешает использованию ntfs-потоков? вопрос, мне кажется, лишь файловой системы, на которой лежит кэш?..

Цитата:

Тебе это нужно для всех файлов, без исключений? А для каталогов нужно?

историку - только для тех которые, историк показвает в истории (типа "корневые" страницы для просмотра) - все связанные с корневой в принципе в этом аспекте не интересны

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


Цитата:

Что-то говорилось про сохранение дат, чтобы Историк (и проч.) их не сбивали. Так нужно или не нужно?

ничего не могу сказать, у меня ничего не сбивает

Цитата:

Историка в глаза не видел,

попробуй, я думаю понравится, расскажешь


Добавлено:
forever
универсальное - это ОБА, полиморфизм т.е.

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


Цитата:

На слабых компах такое решение может сильно тормозить комп.

Хрен редьки не слаще: на слабом компе будет тормозить и собственно NTFS.

И не пойму откуда уже взялись оценки решения которого еще нет? С потоками все ясно, а вот с файлами - отнюдь. Я надеюсь, мысль rs "каждой тваре по паре", тобишь каждому файлу файл-пачпорт так и останется не более чем гипотезой-шуткой.

Цитата:

гипотезой-шуткой

меня больше кидает в дрожь, если появится реализация единого на все файлы индекса

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

DenZzz

Цитата:

Это НЕРЕАЛЬНО мешает! Я уже больше года чищу кэш от всякого старья вручную! Потому что по дате доступа HC удаляет 0 (ноль) файлов, т.к. дата доступа файлов постоянно обновляется!

Кто в этом виноват:
- "Историк" при наполнении истории по файлам кэша;

посмотрел у себя - историк не меняет ни одну из дат файла: создание, изменение, открытие

в чём у тебя проблема7

unreal666

Цитата:

+ Чтение потока происходит быстрее, чем обработка индексного файла

Вероятно это не так. Индексный файл читается один раз и юзается для всех файлов домена из памяти.

mai62

Цитата:

Индексный файл читается один раз и юзается для всех файлов домена из памяти.

Но при этом будет хаваться оперативка. А мне ее и так не хватает.
Да и при загрузке страниц с другого домена, этот индекс в памяти каждый раз придется создавать заново.
forever

Цитата:

Хрен редьки не слаще: на слабом компе будет тормозить и собственно NTFS.

Я не говорю про совсем тормозные компы (типа Pentium 2), а хотя бы с частотой 1ГГц. На таком компе NTFS тормозить не будет, а вот HC с этим индексным файлом - будет.
Т.к. кроме HC еще и другие проги есть (например, проксомитрон). У меня бывает, что Proxomitron до 70% ресурсов CPU сжирает. Это на диалапе, а что будет на выделенке?!

Цитата:

И не пойму откуда уже взялись оценки решения которого еще нет?

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