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

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

Сообщений: 14


« : 16 марта 2008, 04:31:30 »

Все прелести кеша ощутил ишо со времён DOSа при появлении смартдрайвера (кеша винта)
Но какое бы нибыло быстое железо и быстрые каналы, кеш ускоряет однозначно.
Большая часть скорости поцесоров зависит от слаженности работы кеша, так давайте создадим более сложные механизмы работы интернетовского кеша.
Механизмом "Есть ли файл? А не обновить ли нам иво? Обновляем." уже никого не удивышь и уже наситился, совершенствовать некуда.
Расмотрим механизмы копирования файла на примере с CD/DVD привода:
 - обычный: из источника читается, в конец приемника дописываится. Упс царапина, невозможно прочитать файл, удаляем написанное или оставляем тем размером что написали.
 - практичный: создаем приемник забитый нулями (функция выполняется мгновенно хоть 10 гиг выделять) тавоже размера, что и источник, разбиваем источник на блоки, и начинаем писать не нулевые блоки приемника с истоника в любом паправлении, хоть хаотично все сразу (именно не все подряд, а не нулевые, так как вдруг мы его пытались писат в преведущий раз).
По практичному методу работают интернеткачалки и копиры CD/DVD дисков с бедами, сам такой написал для изучения более слаженного механизма.
Перейдите на практичный метод копирования и вы решите проблемму докачки которую тожа бы очень хотелось бы обсуждаемую сдесь.

CoolProxy пользуюсь давно.
Списки "необновлять никогда" и "обновлять всегда" эт канешно харашо но непродуманно, потому как например некоторые "html" никода не обновляются, некоторые роз в сутки, а некоторые при каждом новом запросе. Ужбольно часто обновляется одинаковое.
Посему принятием решения обновлять ли файл болше такото (по настройке) размера (мелкие незачем так детально шуршать) должно быть:
 1. Совпадения размеров файлов источника и приёмника (работаем по практичному методу копирования, либо всё, либо ничего, обрывок недержим, держим полные файли но снулями в случе чего). При подозрении отличия, можно заказать пару случайных блоков с сервера и сравнить с файлом в кеше, При отсутствии блочного доступа на сервере, сравнить пару сотень начальных байт. В CoolProxy размер скачиваемого проставляется до скачивания любого обьекта, а у вас лишь некоторых, нидочет однако.
 2. При отдаче файла (куска файла, для качалок) с кеша смотрим на отсутствие нулей в файле/куске при наличии таковых заказываим файл/куск с сервера.

При внедрении таких механизмов, кеш даст максимальную производительность.

Также хотелось бы видеть настройку "Не сохранять в кеш файлы меньше такогото размера", нет смысла сасорять на винт файлы по 3-50 байт, переводняк кластеров однако.
Сообщить модератору   Записан
Илья
Постоялец
***

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

Сообщений: 186



WWW
« Ответ #1 : 16 марта 2008, 08:39:30 »

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

Вот спасибкИ! я уже собирался это написать Улыбка почтис языка слил Улыбка а на самом деле - отличная мысль! можно будет реализовывать докачку. отличная переспектива!

Цитировать
Также хотелось бы видеть настройку "Не сохранять в кеш файлы меньше такогото размера", нет смысла сасорять на винт файлы по 3-50 байт, переводняк кластеров однако.

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

-------ЗЫ----------
Вообщем если бы mai62 сделал бы еще докачку...... то было бы просто офигенноо!!!!!
-------\ЗЫ----------
Сообщить модератору   Записан

DenZzz
Модератор
*****

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

Сообщений: 5589



« Ответ #2 : 16 марта 2008, 11:44:15 »

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

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

И еще, о каких "не нулевых" блоках может идти речь в контексте закачки файлов с сервера? Большинство форматов больших файлов, передаваемых по интернет, уже максимально сжаты (GZIP, JPG, PDF, архивы и т.п.), т.е. "нулевых" блоков там практически нет!

Цитировать
1. Совпадения размеров файлов источника и приёмника

В простом варианте (без сравнения блоков файлов) это уже реализовано скриптами!

Цитировать
В CoolProxy размер скачиваемого проставляется до скачивания любого обьекта, а у вас лишь некоторых, нидочет однако.

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

Цитировать
Также хотелось бы видеть настройку "Не сохранять в кеш файлы меньше такогото размера", нет смысла сасорять на винт файлы по 3-50 байт, переводняк кластеров однако.

Уже года два, как это было реализовано!  Шокирован  
См. "Настройки / Кэш / Управление - Не сохранять файлы меньше ... байт"

да, кластеры хорошо переводятся при закачки страниц редиректов! они могут иметь от 50 байт до 500 а кластер стандартный на нтфс - 4 Кб

Такие маленькие файлы не переводят кластеры, а хранятся прямо в MFT ! Размер 1 записи MFT = 1 кб.
Кроме того, что для вас важнее - свободное место на диске или скорость закачки страницы? Даже самые маленькие файлы быстрее прочтутся с диска, чем закачаются из инета! Это экономит ваше время и трафик!
« Последнее редактирование: 16 марта 2008, 12:13:23 от DenZzz » Сообщить модератору   Записан
Сергей
Beta tester
*****

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

Сообщений: 621



« Ответ #3 : 16 марта 2008, 11:58:41 »

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

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

Цитировать
новые части можно просто дописывать в конец файла!
Давно надо такую фичу.
« Последнее редактирование: 16 марта 2008, 12:02:51 от Сергей » Сообщить модератору   Записан
anarkidron
Новичок
*

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

Сообщений: 14


« Ответ #4 : 16 марта 2008, 13:30:20 »

Поправвлюсь:
Цитировать
......обновлять ........должно быть:
 1. Совпадения размеров файлов...
Хотел сказать: Не совпадение размеров...
Перефразируя: Делать безусловное обновление объектов только тех, которые отличаются размерами сервер/кеш. Начинать отдавать браузеру блоки обьекта найденного в кеше сразуже после проверки размера, проверяя блок на отсутствие 16ти нулевых байтов подряд, при налии таковых обновляем блок с сервера, при отсутствии блочного доступа к обьекту на сервере тянем объект с начала, дожедаемся блока на котором остановились, отдаем браузеру обновлённый блок.

Добавить список "Проверять содержимое" (или переименовать список "обновлять всегда") для тех случаев когда важно передача актуальных объектов каких как html и cgi. Обьекты этого списка будут проходить сравнение случайных пару блоков (на пару десятков/сотень байт) с сервером, после прохождения сравнения на размер и отсутствия 16ти нулевых байтов подряд при передаче.

Цитировать
Поэтому особой нужны в резервировании диска нет !
я не вижу минусов в этом методе, та хоть даже 20% не будут доконца докачанны всёравно удалится по устариванию. Просто я ишо не пробывал качать качалкими через прокси, как будут обрабатыватся запросы средины файла.
Цитировать
- новые части можно просто дописывать в конец файла!
А как мы узнаем это недокачанный или старый файл который нада заменить новым? Разве что по дате...

Цитировать
С этого места поподробнее! Как узнать размер файла, если сервер не сообщает его в заголовках?
Это невозможно! А когда размер известен, то HC всегда пишет его до скачивания!
Сори, размер html'ов действительно сервер не выдаёт, блин, мудачество какоето. Содержимое дно и тоже, даты разные, размер ниузнать, тупик...

Цитировать
Нулевые блоки не являются достоверным признаком их незанятости.
Не являются, ну перекачаем лишний раз блок с подосрением на недокачку, ну этож не весь файл как сейчас.
Сообщить модератору   Записан
DenZzz
Модератор
*****

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

Сообщений: 5589



« Ответ #5 : 16 марта 2008, 15:15:32 »

Поправвлюсь:Хотел сказать: Не совпадение размеров...
Перефразируя: Делать безусловное обновление объектов только тех, которые отличаются размерами сервер/кеш.

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

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

А смысл всех этих манипуляций? Файл точно изменился, все равно будем его качать целиком. Зачем еще сравнивать блоки с кэшем? Проще отдать то, что прислал сервер, и не нагружать систему анализом блоков! Накладные расходы системных ресурсов будут громадны!

Цитировать
переименовать список "обновлять всегда"

В HandyCache нет такого списка! Или ты сейчас о CoolProxy? Тогда почему на сайте HandyCache?

Цитировать
Обьекты этого списка будут проходить сравнение случайных пару блоков (на пару десятков/сотень байт) с сервером, после прохождения сравнения на размер и отсутствия 16ти нулевых байтов подряд при передаче.

Сравнение пары случайных блоков не гарантирует полное совпадение файлов! Тем более, когда речь идет о динамических страницах (html и cgi)!
Например, на форуме добавился всего один пост, а все оформление осталось прежним, т.е. фактически изменились только пара строк - вероятность, что мы на них случайно наткнемся стремится к нулю!

Цитировать
я не вижу минусов в этом методе, та хоть даже 20% не будут доконца докачанны всёравно удалится по устариванию.

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

Цитировать
Просто я ишо не пробывал качать качалкими через прокси, как будут обрабатыватся запросы средины файла.

Обрабатываться будут через запрос на сервер, писаться в кэш - не будут!
Да и не дело это - пытаться воспроизвести всю работу менеджера закачек. Надо хотя бы разобраться с последовательной однопотоковой докачкой файлов браузером, Windows Update и т.п. Кстати, именно об этом шла речь в теме про докачку файлов...

Цитировать
А как мы узнаем это недокачанный или старый файл который нада заменить новым? Разве что по дате...

Элементарно - у недокачанного файла будет свое временное расширение!
Сообщить модератору   Записан
anarkidron
Новичок
*

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

Сообщений: 14


« Ответ #6 : 16 марта 2008, 16:54:25 »

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

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

Цитировать
Обрабатываться будут через запрос на сервер, писаться в кэш - не будут!
А хотелось бы, например в сети около 100 кампов наверняка найдутся корые бедут тащить одно и тоже.

Цитировать
В HandyCache нет такого списка! Или ты сейчас о CoolProxy? Тогда почему на сайте HandyCache?
CoolProxy помойму уже не разрабатываится, сейчас в режиме сравнения, пользуюсь и тем и тем, путаюсь  Смущен   Маё дело предложить... Просто очень часто генерятяся одни и теже динамические сраницы и немалых размеров, вообразил, что придумал как на этом секономить.  Непонимаю
Сообщить модератору   Записан
anarkidron
Новичок
*

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

Сообщений: 14


« Ответ #7 : 16 марта 2008, 18:07:26 »

Посмотрел скрипт dont_update_file_by_size.zip, прописал у себя, татаки можно узнать размер динамических html. Вы бы хоть дистрибутив пересобрали и включили в него этот скрипт, немогуж я перечитать весь форум, чтоб узнать какие ишо доработки сделали и как их включить у себя.

Запрашываю сраницу этого форума 2 раза подряд:
16.03.2008/17:14:28 local/127.0.0.1 http://handycache.ru/component/option,com_smf/Itemid,10/board,4.0/ 0 67193/417 0 905 "200 OK" З.4
З.4 (Запись в кэш): .*

16.03.2008/17:15:37 local/127.0.0.1 http://handycache.ru/component/option,com_smf/Itemid,10/board,4.0/ 0 67193/417 0 905 "200 OK" З.4
З.4 (Запись в кэш): .*

Размер одинаковый, но второй раз с кеша не берётся.
« Последнее редактирование: 16 марта 2008, 18:42:58 от anarkidron » Сообщить модератору   Записан
DenZzz
Модератор
*****

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

Сообщений: 5589



« Ответ #8 : 16 марта 2008, 20:23:49 »

Размер одинаковый, но второй раз с кеша не берётся.

Попробую объяснить другими словами то, что уже говорил выше... Конечный размер файла в самом начале загрузки можно узнать ТОЛЬКО из заголовка "Content-Length", который посылает сервер в начале своего ответа! Если такого заголовка нет, то узнать окончательный размер невозможно, пока не закачаешь ВЕСЬ файл целиком!
Динамические страницы (в т.ч. и наш форум!) серверы, как правило, посылают БЕЗ заголовка "Content-Length", поэтому их размер изначально нам неизвестен и узнаем мы его только закачав всю страницу ЦЕЛИКОМ!

Вопрос: Как не обновлять файл, если нам даже неизвестен его конечный размер на сервере!?

16.03.2008/17:15:37 local/127.0.0.1 http://handycache.ru/component/option,com_smf/Itemid,10/board,4.0/ 0 67193/417 0 905 "200 OK" З.4
З.4 (Запись в кэш): .*

67193 байт - это значение колонки "Получено". В процессе закачки оно начинает расти от нуля! Что с чем тут сравнивать, чтобы не обновлять этот файл?


P.S. А почему у тебя GZIP отключен? Или экономия трафика тебе не нужна? С GZIP размер этой страницы меньше в 6 раз!
Сообщить модератору   Записан
anarkidron
Новичок
*

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

Сообщений: 14


« Ответ #9 : 16 марта 2008, 21:19:13 »

Цитировать
поэтому их размер изначально нам неизвестен и узнаем мы его только закачав всю страницу ЦЕЛИКОМ!

Сори, пасмотрел скрипт
Код:
if string.find(type,"text/html",1,true) ~= nil then
       -- Вычисляем длину файла в кэше с учетом дописанного HC тэга
       len2 = len + 5 + string.len(type) + 21 + 4
и подумал, что он там всё вычисляет и предсказываит  Смущен
Сообщить модератору   Записан
DenZzz
Модератор
*****

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

Сообщений: 5589



« Ответ #10 : 17 марта 2008, 12:34:23 »

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

Экстрасенсорные способности планируется реализовать не раньше 5-й версии HC !
На выбор пользователя HC будет предсказывать размер страницы с помощью: хрустального шара, карт Таро, рун, звезд и кофейной гущи...  Прикольно
Сообщить модератору   Записан
Илья
Постоялец
***

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

Сообщений: 186



WWW
« Ответ #11 : 17 марта 2008, 15:30:45 »

Цитировать
Экстрасенсорные способности планируется реализовать не раньше 5-й версии HC !
Улыбка Если такими темапами то к 2015 мож и успеем Улыбка
Я наверное уже успею поступить и окончить универ Улыбка Если щас бета 1...
а когда появилась вся эта заваруха?
Сообщить модератору   Записан

Дем
Постоялец
***

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

Сообщений: 167



« Ответ #12 : 24 марта 2008, 17:18:55 »

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

 
Перейти в: