Главная
Форум
Контакты
Купить
Поддержи проект
Поиск
Искать:
Расширенный поиск
[Закрыть]
Правила форума
Войти
Регистрация
Russian
English
HandyCache форум
Главная категория
»
Новые предложения
»
Новый механизм обновленя файлов в кеше
Имя пользователя:
1 час
1 день
1 неделя
1 месяц
Навсегда
Пароль:
Страниц: [
1
]
Вниз
« предыдущая тема
следующая тема »
Отправить эту тему
Печать
Автор
Тема: Новый механизм обновленя файлов в кеше (Прочитано 8872 раз)
0 Пользователей и 1 Гость смотрят эту тему.
anarkidron
Новичок
Репутация: +0/-0
Offline
Сообщений: 14
Новый механизм обновленя файлов в кеше
«
:
16 марта 2008, 04:31:30 »
Все прелести кеша ощутил ишо со времён DOSа при появлении смартдрайвера (кеша винта)
Но какое бы нибыло быстое железо и быстрые каналы, кеш ускоряет однозначно.
Большая часть скорости поцесоров зависит от слаженности работы кеша, так давайте создадим более сложные механизмы работы интернетовского кеша.
Механизмом "Есть ли файл? А не обновить ли нам иво? Обновляем." уже никого не удивышь и уже наситился, совершенствовать некуда.
Расмотрим механизмы копирования файла на примере с CD/DVD привода:
- обычный: из источника читается, в конец приемника дописываится. Упс царапина, невозможно прочитать файл, удаляем написанное или оставляем тем размером что написали.
- практичный: создаем приемник забитый нулями (функция выполняется мгновенно хоть 10 гиг выделять) тавоже размера, что и источник, разбиваем источник на блоки, и начинаем писать
не нулевые
блоки приемника с истоника в любом паправлении, хоть хаотично все сразу (именно не все подряд, а не нулевые, так как вдруг мы его пытались писат в преведущий раз).
По практичному методу работают интернеткачалки и копиры CD/DVD дисков с бедами, сам такой написал для изучения более слаженного механизма.
Перейдите на практичный метод копирования и вы решите проблемму докачки которую тожа бы
очень хотелось бы
обсуждаемую
сдесь
.
CoolProxy
пользуюсь давно.
Списки "необновлять никогда" и "обновлять всегда" эт канешно харашо но непродуманно, потому как например некоторые "html" никода не обновляются, некоторые роз в сутки, а некоторые при каждом новом запросе. Ужбольно часто обновляется одинаковое.
Посему принятием решения обновлять ли файл болше такото (по настройке) размера (мелкие незачем так детально шуршать) должно быть:
1. Совпадения размеров файлов источника и приёмника (работаем по практичному методу копирования, либо всё, либо ничего, обрывок недержим, держим полные файли но снулями в случе чего). При подозрении отличия, можно заказать пару случайных блоков с сервера и сравнить с файлом в кеше, При отсутствии блочного доступа на сервере, сравнить пару сотень начальных байт. В CoolProxy размер скачиваемого проставляется до скачивания любого обьекта, а у вас лишь некоторых, нидочет однако.
2. При отдаче файла (куска файла, для качалок) с кеша смотрим на отсутствие нулей в файле/куске при наличии таковых заказываим файл/куск с сервера.
При внедрении таких механизмов, кеш даст максимальную производительность.
Также хотелось бы видеть настройку "Не сохранять в кеш файлы меньше такогото размера", нет смысла сасорять на винт файлы по 3-50 байт, переводняк кластеров однако.
Сообщить модератору
Записан
Илья
Постоялец
Репутация: +0/-3
Offline
Сообщений: 186
Re: Новый механизм обновленя файлов в кеше
«
Ответ #1 :
16 марта 2008, 08:39:30 »
Цитата: anarkidron от 16 марта 2008, 04:31:30
- практичный: создаем приемник забитый нулями (функция выполняется мгновенно хоть 10 гиг выделять) тавоже размера, что и источник, разбиваем источник на блоки, и начинаем писать
не нулевые
блоки приемника с истоника в любом паправлении, хоть хаотично все сразу (именно не все подряд, а не нулевые, так как вдруг мы его пытались писат в преведущий раз).
Вот спасибкИ! я уже собирался это написать
почтис языка слил
а на самом деле - отличная мысль! можно будет реализовывать докачку. отличная переспектива!
Цитировать
Также хотелось бы видеть настройку "Не сохранять в кеш файлы меньше такогото размера", нет смысла сасорять на винт файлы по 3-50 байт, переводняк кластеров однако.
Вот это тоже отличная идея!!! да, кластеры хорошо переводятся при закачки страниц редиректов! они могут иметь от 50 байт до 500 а кластер стандартный на
нтфс - 4 Кб
-------ЗЫ----------
Вообщем если бы
mai62
сделал бы еще докачку...... то было бы просто офигенноо!!!!!
-------\ЗЫ----------
Сообщить модератору
Записан
HC - Вещь!!!
Юлог Юного Сисадмина
DenZzz
Модератор
Репутация: +179/-11
Offline
Сообщений: 5589
Re: Новый механизм обновленя файлов в кеше
«
Ответ #2 :
16 марта 2008, 11:44:15 »
Цитата: anarkidron от 16 марта 2008, 04:31:30
- практичный: создаем приемник забитый нулями (функция выполняется мгновенно хоть 10 гиг выделять) тавоже размера, что и источник, разбиваем источник на блоки, и начинаем писать
не нулевые
блоки приемника с истоника в любом паправлении, хоть хаотично все сразу (именно не все подряд, а не нулевые, так как вдруг мы его пытались писат в преведущий раз).
То, что хорошо для интернет-качалок и копиров CD/DVD дисков, не всегда хорошо для HC ! Качалки, как правило, скачивают файлы по частям в несколько потоков одновременно, а браузеры всегда в один поток последовательно и самого начала! Поэтому особой нужны в резервировании диска нет - новые части можно просто дописывать в конец файла!
Кроме того, ниже ты пишешь про расход кластеров на мелкие файлы... На резервирование места под закачку файлов уйдет гораздо больше дискового пространства! Причем некоторые файлы так и не будут никогда докачены, а зарезервированное под них место останется на диске, пока не удалишь!
И еще, о каких "не нулевых" блоках может идти речь в контексте закачки файлов с сервера? Большинство форматов больших файлов, передаваемых по интернет, уже максимально сжаты (GZIP, JPG, PDF, архивы и т.п.), т.е. "нулевых" блоков там практически нет!
Цитировать
1. Совпадения размеров файлов источника и приёмника
В простом варианте (без сравнения блоков файлов) это уже реализовано
скриптами
!
Цитировать
В CoolProxy размер скачиваемого проставляется до скачивания любого обьекта, а у вас лишь некоторых, нидочет однако.
С этого места поподробнее! Как узнать размер файла, если сервер не сообщает его в заголовках?
Это невозможно! А когда размер известен, то HC всегда пишет его до скачивания!
Цитировать
Также хотелось бы видеть настройку "Не сохранять в кеш файлы меньше такогото размера", нет смысла сасорять на винт файлы по 3-50 байт, переводняк кластеров однако.
Уже года два, как это было реализовано!
См. "
Настройки / Кэш / Управление - Не сохранять файлы меньше ... байт
"
Цитата: Илья от 16 марта 2008, 08:39:30
да, кластеры хорошо переводятся при закачки страниц редиректов! они могут иметь от 50 байт до 500 а кластер стандартный на
нтфс - 4 Кб
Такие маленькие файлы не переводят кластеры, а хранятся прямо в MFT ! Размер 1 записи MFT = 1 кб.
Кроме того, что для вас важнее - свободное место на диске или скорость закачки страницы? Даже самые маленькие файлы быстрее прочтутся с диска, чем закачаются из инета! Это экономит ваше время и трафик!
«
Последнее редактирование: 16 марта 2008, 12:13:23 от DenZzz
»
Сообщить модератору
Записан
Сергей
Beta tester
Репутация: +9/-2
Offline
Сообщений: 621
Re: Новый механизм обновленя файлов в кеше
«
Ответ #3 :
16 марта 2008, 11:58:41 »
Нулевые блоки не являются достоверным признаком их незанятости. Качалки в этих ситуациях дописывают в конец файла индексный блок, который обрезается при завершении закачки.
И еще мы тут уже выяснили, что мелкие файлы не засоряют винт. Они целиком сохраняются в записи MFT и дополнительный кластер не выделяется. Так что такая опция не даст выигрыша.
Цитировать
новые части можно просто дописывать в конец файла!
Давно надо такую фичу.
«
Последнее редактирование: 16 марта 2008, 12:02:51 от Сергей
»
Сообщить модератору
Записан
anarkidron
Новичок
Репутация: +0/-0
Offline
Сообщений: 14
Re: Новый механизм обновленя файлов в кеше
«
Ответ #4 :
16 марта 2008, 13:30:20 »
Поправвлюсь:
Цитировать
......обновлять ........должно быть:
1. Совпадения размеров файлов...
Хотел сказать:
Не
совпадение размеров...
Перефразируя: Делать безусловное обновление объектов только тех, которые отличаются размерами сервер/кеш. Начинать отдавать браузеру блоки обьекта найденного в кеше сразуже после проверки размера, проверяя блок на отсутствие 16ти нулевых байтов подряд, при налии таковых обновляем блок с сервера, при отсутствии блочного доступа к обьекту на сервере тянем объект с начала, дожедаемся блока на котором остановились, отдаем браузеру обновлённый блок.
Добавить список "Проверять содержимое" (или переименовать список "обновлять всегда") для тех случаев когда
важно
передача актуальных объектов каких как
html
и
cgi
. Обьекты этого списка будут проходить сравнение случайных пару блоков (на пару десятков/сотень байт) с сервером, после прохождения сравнения на размер и отсутствия 16ти нулевых байтов подряд при передаче.
Цитировать
Поэтому особой нужны в резервировании диска нет !
я не вижу минусов в этом методе, та хоть даже 20% не будут доконца докачанны всёравно удалится по устариванию. Просто я ишо не пробывал качать качалкими через прокси, как будут обрабатыватся запросы средины файла.
Цитировать
- новые части можно просто дописывать в конец файла!
А как мы узнаем это недокачанный или старый файл который нада заменить новым? Разве что по дате...
Цитировать
С этого места поподробнее! Как узнать размер файла, если сервер не сообщает его в заголовках?
Это невозможно! А когда размер известен, то HC всегда пишет его до скачивания!
Сори, размер html'ов действительно сервер не выдаёт, блин, мудачество какоето. Содержимое дно и тоже, даты разные, размер ниузнать, тупик...
Цитировать
Нулевые блоки не являются достоверным признаком их незанятости.
Не являются, ну перекачаем лишний раз блок с подосрением на недокачку, ну этож не весь файл как сейчас.
Сообщить модератору
Записан
DenZzz
Модератор
Репутация: +179/-11
Offline
Сообщений: 5589
Re: Новый механизм обновленя файлов в кеше
«
Ответ #5 :
16 марта 2008, 15:15:32 »
Цитата: anarkidron от 16 марта 2008, 13:30:20
Поправвлюсь:Хотел сказать:
Не
совпадение размеров...
Перефразируя: Делать безусловное обновление объектов только тех, которые отличаются размерами сервер/кеш.
Еще больше все запутал!
Если размеры совпадают, то безусловно НЕ обновляем файл? Так сейчас и делает скрипт!
А если размеры НЕ совпадают, то какой смысл проверять блоки - файл же точно изменился!
Цитировать
при отсутствии блочного доступа к обьекту на сервере тянем объект с начала, дожедаемся блока на котором остановились, отдаем браузеру обновлённый блок.
А смысл всех этих манипуляций? Файл точно изменился, все равно будем его качать целиком. Зачем еще сравнивать блоки с кэшем? Проще отдать то, что прислал сервер, и не нагружать систему анализом блоков! Накладные расходы системных ресурсов будут громадны!
Цитировать
переименовать список "обновлять всегда"
В HandyCache нет такого списка! Или ты сейчас о CoolProxy? Тогда почему на сайте HandyCache?
Цитировать
Обьекты этого списка будут проходить сравнение случайных пару блоков (на пару десятков/сотень байт) с сервером, после прохождения сравнения на размер и отсутствия 16ти нулевых байтов подряд при передаче.
Сравнение пары случайных блоков не гарантирует полное совпадение файлов! Тем более, когда речь идет о
динамических
страницах (html и cgi)!
Например, на форуме добавился всего один пост, а все оформление осталось прежним, т.е. фактически изменились только пара строк - вероятность, что мы на них случайно наткнемся стремится к нулю!
Цитировать
я не вижу минусов в этом методе, та хоть даже 20% не будут доконца докачанны всёравно удалится по устариванию.
То ты кластеры мелких файлов предлагал экономить, а теперь оказалось, что 20% недокаченных файлов в кэше - все равно! А ты представь, что пользователь начал качать какой-нибудь DVD-образ и забросил. Вот и будут такие файлы занимать гигабайты у тебя в кэше, пока не "устареют"...
Цитировать
Просто я ишо не пробывал качать качалкими через прокси, как будут обрабатыватся запросы средины файла.
Обрабатываться будут через запрос на сервер, писаться в кэш - не будут!
Да и не дело это - пытаться воспроизвести всю работу менеджера закачек. Надо хотя бы разобраться с последовательной однопотоковой докачкой файлов браузером, Windows Update и т.п. Кстати, именно об этом шла речь в теме про
докачку файлов
...
Цитировать
А как мы узнаем это недокачанный или старый файл который нада заменить новым? Разве что по дате...
Элементарно - у недокачанного файла будет свое временное расширение!
Сообщить модератору
Записан
anarkidron
Новичок
Репутация: +0/-0
Offline
Сообщений: 14
Re: Новый механизм обновленя файлов в кеше
«
Ответ #6 :
16 марта 2008, 16:54:25 »
Цитировать
Еще больше все запутал!
Если размеры совпадают, то безусловно НЕ обновляем файл? Так сейчас и делает скрипт!
А если размеры НЕ совпадают, то какой смысл проверять блоки - файл же точно изменился!
Вначале не верно написал, потом поправился "обновлять при
не
совпадении размера", никто и не предлагал сравнивать файлы разного размера. Скрипт попробую.
Цитировать
Например, на форуме добавился всего один пост, а все оформление осталось прежним, т.е. фактически изменились только пара строк - вероятность, что мы на них случайно наткнемся стремится к нулю!
Размер изменится.
Цитировать
Обрабатываться будут через запрос на сервер, писаться в кэш - не будут!
А хотелось бы, например в сети около 100 кампов наверняка найдутся корые бедут тащить одно и тоже.
Цитировать
В HandyCache нет такого списка! Или ты сейчас о CoolProxy? Тогда почему на сайте HandyCache?
CoolProxy помойму уже не разрабатываится, сейчас в режиме сравнения, пользуюсь и тем и тем, путаюсь
Маё дело предложить... Просто очень часто генерятяся одни и теже динамические сраницы и немалых размеров, вообразил, что придумал как на этом секономить.
Сообщить модератору
Записан
anarkidron
Новичок
Репутация: +0/-0
Offline
Сообщений: 14
Re: Новый механизм обновленя файлов в кеше
«
Ответ #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
Сообщений: 5589
Re: Новый механизм обновленя файлов в кеше
«
Ответ #8 :
16 марта 2008, 20:23:49 »
Цитата: anarkidron от 16 марта 2008, 18:07:26
Размер одинаковый, но второй раз с кеша не берётся.
Попробую объяснить другими словами то, что уже говорил выше... Конечный размер файла в самом начале загрузки можно узнать ТОЛЬКО из заголовка "Content-Length", который посылает сервер в начале своего ответа! Если такого заголовка нет, то узнать окончательный размер невозможно, пока не закачаешь ВЕСЬ файл целиком!
Динамические страницы (в т.ч. и наш форум!) серверы, как правило, посылают БЕЗ заголовка "Content-Length", поэтому их размер изначально нам неизвестен и узнаем мы его только закачав всю страницу ЦЕЛИКОМ!
Вопрос: Как не обновлять файл, если нам даже неизвестен его конечный размер на сервере!?
Цитата: anarkidron от 16 марта 2008, 18:07:26
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
Сообщений: 14
Re: Новый механизм обновленя файлов в кеше
«
Ответ #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
Сообщений: 5589
Re: Новый механизм обновленя файлов в кеше
«
Ответ #10 :
17 марта 2008, 12:34:23 »
Цитата: anarkidron от 16 марта 2008, 21:19:13
и подумал, что он там всё вычисляет и предсказываит
Экстрасенсорные способности планируется реализовать не раньше 5-й версии HC !
На выбор пользователя HC будет предсказывать размер страницы с помощью: хрустального шара, карт Таро, рун, звезд и кофейной гущи...
Сообщить модератору
Записан
Илья
Постоялец
Репутация: +0/-3
Offline
Сообщений: 186
Re: Новый механизм обновленя файлов в кеше
«
Ответ #11 :
17 марта 2008, 15:30:45 »
Цитировать
Экстрасенсорные способности планируется реализовать не раньше 5-й версии HC !
Если такими темапами то к 2015 мож и успеем
Я наверное уже успею поступить и окончить универ
Если щас бета 1...
а когда появилась вся эта заваруха?
Сообщить модератору
Записан
HC - Вещь!!!
Юлог Юного Сисадмина
Дем
Постоялец
Репутация: +6/-3
Offline
Сообщений: 167
Re: Новый механизм обновленя файлов в кеше
«
Ответ #12 :
24 марта 2008, 17:18:55 »
Вообще, в единовременном резервировании места под файл смысл есть - это уменьшает фрагментацию.
Хотя наверно имеет смысл ограничить максимальный резервируемый размер скажем десятком мегабайт.
Ну и если закачка прервалась, особенно со стороны клиента - освобождать.
Сообщить модератору
Записан
Страниц: [
1
]
Вверх
Отправить эту тему
Печать
« предыдущая тема
следующая тема »
Перейти в:
Пожалуйста, выберите назначение:
-----------------------------
Главная категория
-----------------------------
=> Общие вопросы
=> Новые предложения
=> Дополнения, плагины
=> Сжатие трафика
=> English forum
=> Indonesian forum
-----------------------------
Гостевая
-----------------------------
=> Гостевая
-----------------------------
Дела домашние
-----------------------------
=> Сайт и форум HandyCache
=> Курилка
© 2006-2014 HandyCache Team. Все права защищены.
Загружается...