+  HandyCache форум
|-+  Главная категория» Новые предложения» Доработка процедуры: Очистка кэша
Имя пользователя:
Пароль:
Страниц: [1] 2 3 ... 6   Вниз
  Отправить эту тему    Печать  
Автор Тема: Доработка процедуры: Очистка кэша  (Прочитано 102453 раз)
0 Пользователей и 1 Гость смотрят эту тему.
DenZzz
Модератор
*****

Репутация: +179/-11
Offline Offline

Сообщений: 5589



« : 12 января 2007, 22:25:56 »

Описание проблемы:

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

Предложения по улучшению:

  • Создать список (поле) исключений из очистки (для сайтов/файлов, которые нельзя удалять);
  • Очищать кэш, используя "Черный список" и "Преобразование URL", если "Белый список" их не отменяет;
  • Продумать процедуру избавления от "разовых" и "старых" файлов (сайтов), т.к. дата доступа постоянно сбивается от работы антивирусов, архиваторов, hc.Historian и т.п. или может быть отключена в NTFS (NtfsDisableLastAccessUpdate=1)
    Вариант 1: Поручить HC при чтении из каталога обновлять его дату модицикации, чтобы потом по ним чистить кэш;
    Вариант 2: Писать дату доступа к каталогу (или файлу, если это не сильно замедлит работу) в индексный файл.
  • Обеспечить очистку кэша не с фиксированной даты, а с количества дней от текущей даты (например - 7 дней, 1 месяц и т.д.) и, желательно, делать это автоматически по расписанию (при выходе из HC, раз в неделю, в месяц и т.д.).
  • Добавить в список операций переименование файлов, в т.ч. с использованием списка "Преобразование URL". Получим встроенный конвертор кэша.
  • Добавить возможность предварительного просмотра списка удаляемых/переименовываемых файлов.


=== Перенесено с Wiki ===
« Последнее редактирование: 10 марта 2007, 16:45:57 от DenZzz » Сообщить модератору   Записан
Oneri
Новичок
*

Репутация: +2/-0
Offline Offline

Сообщений: 34


« Ответ #1 : 01 февраля 2007, 11:53:01 »

а если при очистки кеша использовать не дату последнего доступа к файлу а например создания или изменения файла
ИХМО изменения файла наверное подошло - не должно оно правится антивирусами (правда при доступе к файлу ее придется обновлять)
Сообщить модератору   Записан
DenZzz
Модератор
*****

Репутация: +179/-11
Offline Offline

Сообщений: 5589



« Ответ #2 : 09 февраля 2007, 00:41:49 »

Oneri

Цитировать
ИХМО изменения файла наверное подошло - не должно оно правится антивирусами (правда при доступе к файлу ее придется обновлять)

Даты изменения файлов используются при проверке "Критериев свежести" в списке "Не обновлять" и для формирования заголовков "lf-Modified-Since". Если даты изменения файлов обновлять при каждом чтении из кэша, то вышеназванные опции не смогут правильно работать и эти файлы в кэше никогда не обновятся!
Сообщить модератору   Записан
Дем
Постоялец
***

Репутация: +6/-3
Offline Offline

Сообщений: 167



« Ответ #3 : 10 февраля 2007, 15:06:01 »

Цитировать
Даты изменения файлов используются при проверке "Критериев свежести" в списке "Не обновлять" и для формирования заголовков "lf-Modified-Since". Если даты изменения файлов обновлять при каждом чтении из кэша, то вышеназванные опции не смогут правильно работать и эти файлы в кэше никогда не обновятся!
Угу, есть такое.
А если под это дело использовать "дату создания"? Сейчас она не используется - что если её выставлять в дату, переданную с сервера и работать с указанным на основе её? А "дату модификации" использовать для времени последнего использования.
Сообщить модератору   Записан
DenZzz
Модератор
*****

Репутация: +179/-11
Offline Offline

Сообщений: 5589



« Ответ #4 : 10 февраля 2007, 15:47:50 »

А если под это дело использовать "дату создания"?

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

Цитировать
что если её выставлять в дату, переданную с сервера и работать с указанным на основе её?

Дата, переданная с сервера по большому счету нам не нужна, т.к. достаточно системной даты на момент сохранения файла - даты модификации файла, которое сохраняет сама файловая система. Это экономит время и ресурсы на обработку заголовка "Date" и изменение дат на диске.
Сообщить модератору   Записан
Дем
Постоялец
***

Репутация: +6/-3
Offline Offline

Сообщений: 167



« Ответ #5 : 12 февраля 2007, 23:49:03 »

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

Но я собственно предлагал другое - при обращении обновлять дату модификации, а браузеру в lf-Modified-Since отдавать дату создания - не важно с сервера она или нет.
Ресурсов это больше не займёт (система всё равно обновляет дату доступа для данного файла), но позволит избежать интерференции с обновлением даты доступа от других программ.
Сообщить модератору   Записан
DenZzz
Модератор
*****

Репутация: +179/-11
Offline Offline

Сообщений: 5589



« Ответ #6 : 13 февраля 2007, 00:32:41 »

Но я собственно предлагал другое - при обращении обновлять дату модификации, а браузеру в lf-Modified-Since отдавать дату создания - не важно с сервера она или нет.

Дата создания файла записывается файловой системой при первом сохранении файла на диск и впоследствии при модификации/перезаписи файла эта дата сама НЕ обновляется!
А принудительно ее обновлять, как я уже говорил: во-первых, не всегда дает система, а во-вторых, это лишние затраты ресурсов!
В общем, предложение не годится!
« Последнее редактирование: 13 февраля 2007, 00:39:23 от DenZzz » Сообщить модератору   Записан
NothingAnother
Beta tester
*****

Репутация: +7/-2
Offline Offline

Сообщений: 434

Spoiler


« Ответ #7 : 13 февраля 2007, 07:51:44 »

принудительно ее обновлять, как я уже говорил: во-первых, не всегда дает система
Это легко обходится, но:
Цитировать
это лишние затраты ресурсов
и немалые (временные), учитывая, что речь идёт о дисковых операциях
Сообщить модератору   Записан

Мы тоже не всего читали Шнитке!..
© В. Вишневский
Дем
Постоялец
***

Репутация: +6/-3
Offline Offline

Сообщений: 167



« Ответ #8 : 14 февраля 2007, 09:57:22 »

Дата создания файла записывается файловой системой при первом сохранении файла на диск и впоследствии при модификации/перезаписи файла эта дата сама НЕ обновляется!
А принудительно ее обновлять, как я уже говорил: во-первых, не всегда дает система, а во-вторых, это лишние затраты ресурсов!
В общем, предложение не годится!
Блин, ещё раз повторяю: Дату создания мы не трогаем. Какая получилась - такая получилась.
А при чтении файла из кеша мы её только читаем и отдаём браузеру.
А вот дату модификации  обновляем на текущую и используем её для анализа кеша на предмет доступа.
Сообщить модератору   Записан
DenZzz
Модератор
*****

Репутация: +179/-11
Offline Offline

Сообщений: 5589



« Ответ #9 : 14 февраля 2007, 13:46:29 »

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

Блин, еще раз объясняю: какой смысл отдавать браузеру (серверу) дату создания, если она была записана год назад и с тех пор не обновлялась, хотя сам файл уже 100 раз был переписан! Дата создания уже 100 раз устарела, поэтому сервер будет каждый раз отправлять файл повторно!

Если у тебя кэш на NTFS - посмотри даты создания файлов, которые часто перезаписываются в кэше! Их даты создания намного старее дат их последней модификации!
Сообщить модератору   Записан
Михаил
Gold beta tester
*****

Репутация: +337/-14
Offline Offline

Сообщений: 5513



« Ответ #10 : 15 февраля 2007, 14:17:36 »

DenZzz
Я думаю, Дем имеет ввиду осуществлять перезапись файла не путем его открытия-стирания содержимого-прописывания нового-закрытия (т.е. изменения), а путем удаления файла-создания нового. Если можешь, оцени выгодность/невыгодность этого варианта. Я оценить не могу.
Сообщить модератору   Записан
Death_Master
Beta tester
*****

Репутация: +1/-1
Offline Offline

Сообщений: 82


« Ответ #11 : 16 февраля 2007, 05:21:18 »

В базу! (имхо)
Сообщить модератору   Записан
Дем
Постоялец
***

Репутация: +6/-3
Offline Offline

Сообщений: 167



« Ответ #12 : 16 февраля 2007, 10:39:59 »

Цитировать
Блин, еще раз объясняю: какой смысл отдавать браузеру (серверу) дату создания, если она была записана год назад и с тех пор не обновлялась, хотя сам файл уже 100 раз был переписан! Дата создания уже 100 раз устарела, поэтому сервер будет каждый раз отправлять файл повторно!
Вообще говоря, в большинстве случаев при закачке создаётся новый файл *.new/*.chk, а старый удляется. Соответственно дата создания файла тоже новая Улыбка
А указанное тобой происходит в основном у динамического контента, который всё равно подлежит безусловному обновлению независимо от дат.

ЗЫ: И предлагаю на этом данный спор закрыть. Потому как моё предложение вполне может быть реализовано путём неких дополнительных модификаций программы.
А вот делать ли их - это уже на усмотрение автора. Наше дело предложить, его - отфильтровать предложенное.
« Последнее редактирование: 16 февраля 2007, 10:44:33 от Дем » Сообщить модератору   Записан
DenZzz
Модератор
*****

Репутация: +179/-11
Offline Offline

Сообщений: 5589



« Ответ #13 : 16 февраля 2007, 11:40:29 »

Вообще говоря, в большинстве случаев при закачке создаётся новый файл *.new/*.chk, а старый удляется. Соответственно дата создания файла тоже новая Улыбка

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

Цитировать
моё предложение вполне может быть реализовано путём неких дополнительных модификаций программы.

За счет увеличения расходования системных ресурсов, как и если пойти "путем удаления файла-создания нового", предложенным Михаилом выше! Что сводит ценность твоего предложения к нулю! Подмигивающий
« Последнее редактирование: 16 февраля 2007, 11:52:12 от DenZzz » Сообщить модератору   Записан
mai62
Автор HC
*****

Репутация: +226/-4
Offline Offline

Сообщений: 6383


« Ответ #14 : 16 февраля 2007, 12:14:12 »

Дем
Цитировать
Вообще говоря, в большинстве случаев при закачке создаётся новый файл *.new/*.chk, а старый удляется. Соответственно дата создания файла тоже новая
Я тоже так думал про дату создания файла. Но, к моему удивлению, я обнаружил (речь о FAT32), что если удалить файл, а потом создать файл заново с тем же именем или присвоить это имя переименованием, то система с вероятностью 0,9 присвоит ему дату создания старого файла (выглядит так, что система помнит про этот удаленный файл и пытается 'восстановить справедливость'). Причем система не дает даже произвольно установить желаемую дату содания с помощью функций API. Несколько месяцев назад я  потратил чуть не целый день, чтобы найти способ обойти этот трабл, но так и не нашел надежного варианта.
Сообщить модератору   Записан
DIGGER
Старожил
****

Репутация: +14/-3
Offline Offline

Сообщений: 312



« Ответ #15 : 21 февраля 2007, 09:33:15 »

Просто моё мнение:
Вариант 2: Писать дату доступа к каталогу (или файлу, если это не сильно замедлит работу) в индексный файл. [/li][/list]
Однозначно, самое безпроблемное решение. А потом, когда-нибудь, можно и поискать альтернативные пути.
Сейчас у меня получается я чищу кеш каждые два-четыре дня ВРУЧНУЮ. невесело...

Кто-нибудь знает, когда выйдет новая версия HC? или, хотя бы, "не раньше чем". Зачем мне это? та так... для "общего развития" Улыбка.
Сообщить модератору   Записан
Rick
Администратор
*****

Репутация: +15/-1
Offline Offline

Сообщений: 868


WWW
« Ответ #16 : 21 февраля 2007, 09:55:10 »

Однозначно, самое безпроблемное решение.
Проблемы начинаются, когда начинаешь думать как это реализовать. Грустный
Сообщить модератору   Записан
Михаил
Gold beta tester
*****

Репутация: +337/-14
Offline Offline

Сообщений: 5513



« Ответ #17 : 21 февраля 2007, 17:52:15 »

Хочу предложить ввести автоматическую очистку кэша. Цель - разгрузка пользователя от забот и временных затрат, связанных с ручной регулировкой размера кэша.
Принцип следующий. Задаем:
- максимально допустимый размер кэша (в МБ) или
- относительный максимально допустимый размер кэша (в % от объема носителя) или
- минимально допустимый размер свободного дискового пространства (в МБ) или
- относительный минимально допустимый размер свободного места (в % от объема носителя).
Текущий размер кэша накапливаем в переменной, содержащейся, например, в файле индекса.
Проверяем/изменяем значение этой переменной при каждой записи в кэш и в процессе удаления файлов из кэша. Как только размер кэша подходит к критическому можно предложить два варианта:
- оповестить пользователя и с его согласия существенно (т.е. чтоб долго к этому вопросу не возвращаться) очистить кэш по предварительно заданным параметрам;
- включить процедуру очистки в реальном времени по предварительно заданным критериям с одновременным оповещением пользователя (например, цветом иконки в трее).
Второй вариант, на мой взгляд, лучше с точки зрения экономии трафика/времени. Чтоб он не стал боком с точки зрения производительности, надо продумать алгоритм.
Предварительно задаваемые пользователем критерии:
- по дате последнего доступа;
- по дате последнего доступа + частоте обращений;
- может, еще какие...
Алгоритм очистки в реальном времени по дате последнего доступа крупными штрихами видится таким. В индексе держим отсортированный по последней дате доступа связный список ссылок на записи индекса (имена сайтов или URL в зависимости от того, как хотим чистить - сайтами целиком и отдельными файлами). Работаем так: Получаем очередной URL для записи в кэш. Если он уже есть в индексе, то он переносится в конец списка; одновременно корректируется общий размер кэша. Если его нет - добавляем его в конец списка и приплюсовываем его размер к размеру кэша. Если размер кэша начинает превышать заданный, удаляем первый объект списка. Если все равно превышает - второй и т.д. пока не остановимся.
Вроде особых затрат не предвидится... Но может, это только на первый взгляд?
Давайте обсудим...
Сообщить модератору   Записан
DenZzz
Модератор
*****

Репутация: +179/-11
Offline Offline

Сообщений: 5589



« Ответ #18 : 21 февраля 2007, 23:01:28 »

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

Ух ты! Т.е. постоянно сортируем и строим этот список из 55 тыс. записей в памяти? А ты представляешь, сколько это отъест процессорного времени и памяти?!

Например, включение опций "Не показывать в Мониторе" и отключение ведения лога, по опытам, примерно на 20-30% ускоряет загрузку страниц в браузере!
Представляю, на сколько замедлится работа от постоянной сортировки многотысячного списка...
Сообщить модератору   Записан
Михаил
Gold beta tester
*****

Репутация: +337/-14
Offline Offline

Сообщений: 5513



« Ответ #19 : 22 февраля 2007, 01:47:07 »

DenZzz
Цитировать
постоянно сортируем...
от постоянной сортировки...
Перечитал свой пост еще раз... И снова не нашел выделенное красным?! Непонимаю
« Последнее редактирование: 22 февраля 2007, 02:05:25 от Михаил » Сообщить модератору   Записан
Страниц: [1] 2 3 ... 6   Вверх
  Отправить эту тему    Печать  

 
Перейти в: