Главная
Форум
Контакты
Купить
Поддержи проект
Поиск
Искать:
Расширенный поиск
[Закрыть]
Правила форума
Войти
Регистрация
Russian
English
HandyCache форум
Главная категория
»
Новые предложения
»
Увеличение эффективности кэша клиента (I-M-S, I-N-M, Expires и т.п.)
Имя пользователя:
1 час
1 день
1 неделя
1 месяц
Навсегда
Пароль:
Страниц:
1
2
3
[
Все
]
Вниз
« предыдущая тема
следующая тема »
Отправить эту тему
Печать
Автор
Тема: Увеличение эффективности кэша клиента (I-M-S, I-N-M, Expires и т.п.) (Прочитано 44359 раз)
0 Пользователей и 1 Гость смотрят эту тему.
Михаил
Gold beta tester
Репутация: +337/-14
Offline
Сообщений: 5513
Увеличение эффективности кэша клиента (I-M-S, I-N-M, Expires и т.п.)
«
:
01 сентября 2007, 01:21:24 »
Недавно с удивлением обнаружил, что многие серверы отвечают на If-Modified-Since "304 Not Modified", только если дата в IMS
точно
совпадает с датой Last-Modified! Если она отличается, то даже если файл реально не изменялся, сервер все равно отвечает "200 OK", и НС грузит весь файл заново.
Беру, к примеру, сайт
http://handycache.narod.ru/
Запрос
Код:
GET / HTTP/1.0
Host: handycache.narod.ru
If-Modified-Since: Mon, 07 May 2007 15:41:12 GMT
Connection: close
Вернет "304"
А отличающийся всего на минуту
Код:
GET / HTTP/1.0
Host: handycache.narod.ru
If-Modified-Since: Mon, 07 May 2007 15:42:12 GMT
Connection: close
вернет уже "200".
Обидно, да!!! Тем более что как только нашел такой трабл, так присмотрелся и таких серверов среди своих обиходных мест посещения нашел не много, а ОЧЕНЬ много!
Получается, не экономится нифига, имеется только большой потенциал, который будет реализован, если запоминать присланную при первом обращении дату Last-Modified и в последующем слать в условном запросе именно ее.
All
Гляньте, плиз, у себя. Это же, для примера, прослеживается при загрузке
http://www.xs4all.nl/~kassiesa/bert/uefa/data/method3/crank2008.html
http://mumurik.narod.ru/hc.html
Реализовано с версии 1.0 RC2 (1.0.0.193) согласно алгоритму, описанному
здесь...
В
HandyCache.ini
добавлены новые опции:
StopDownloadingOldFiles=True/False
- по п.1
алгоритма
. По умолчанию отключено (False).
SendExpiresHeaderField=True/False
- по п.5
алгоритма
. По умолчанию отключено (False).
«
Последнее редактирование: 05 августа 2009, 12:20:49 от DenZzz
»
Сообщить модератору
Записан
Кирилл
Beta tester
Репутация: +5/-1
Offline
Сообщений: 124
Re: Размер экономии от кэширования зависит от даты в If-Modified-Since
«
Ответ #1 :
01 сентября 2007, 12:13:01 »
А что тут удивляться?
Не зря в HTTP 1.1 этот параметр назвали уже E-Tag - ибо время требует реализации глобальных часов и т.п. и т.д., а нам нужна лишь контрольная сумма для проверки измененности объекта.
Еще один (и очень весомый) довод в пользу хранения заголовков в кеше.
Сообщить модератору
Записан
Михаил
Gold beta tester
Репутация: +337/-14
Offline
Сообщений: 5513
Re: Размер экономии от кэширования зависит от даты в If-Modified-Since
«
Ответ #2 :
01 сентября 2007, 13:13:30 »
Цитата: Кирилл от 01 сентября 2007, 12:13:01
А что тут удивляться?
Получается, что на практике название заголовка чаще всего не соответствует действительности. Его б тогда назвать "IfLastModified=".
Честно говоря, ужаснулся - у меня на этом теряется уйма возможной экономии. Ведь
постоянно
тянутся из сети html-ы по 50-200 КБ, которые должны были б просто браться из кэша.
Сообщить модератору
Записан
Кирилл
Beta tester
Репутация: +5/-1
Offline
Сообщений: 124
Re: Размер экономии от кэширования зависит от даты в If-Modified-Since
«
Ответ #3 :
01 сентября 2007, 13:51:36 »
Цитата: Михаил от 01 сентября 2007, 13:13:30
Получается, что на практике название заголовка чаще всего не соответствует действительности. Его б тогда назвать "IfLastModified=".
Честно говоря, ужаснулся - у меня на этом теряется уйма возможной экономии. Ведь
постоянно
тянутся из сети html-ы по 50-200 КБ, которые должны были б просто браться из кэша.
Дело не в названии заголовка - дело в реализации HTTP-сервера. Поскольку кеширующие браузеры и так хранят LastModified, следовательно именно его они и вставят при следующем запросе. Отсюда и оптимизация на сервере - можно вместо разбора строки в заголовке просто сравнить ее с оригинальной.
Давно пора избавить HC от гадания на сигнатурах и временах создания.
А если кому-то надо извращаться с кешем на FAT32 - пусть отключает хранение заголовков в настройках.
Сообщить модератору
Записан
DenZzz
Модератор
Репутация: +179/-11
Offline
Сообщений: 5589
Re: Размер экономии от кэширования зависит от даты в If-Modified-Since
«
Ответ #4 :
08 сентября 2007, 21:44:30 »
Цитата: Михаил от 01 сентября 2007, 01:21:24
Недавно с удивлением обнаружил, что многие серверы отвечают на If-Modified-Since "304 Not Modified", только если дата в IMS
точно
совпадает с датой Last-Modified!
Я наблюдал ситуацию, когда сервер вообще игнорировал "If-Modified-Since", видимо ожидая присутствия "If-None-Match", о чем я уже писал
вот здесь
!
Но и это не панацея! Например,
вот здесь
был пример, когда сервер по непонятной причине игнорировал совершенно правильные заголовки "I-M-S" и "I-N-M" !
Цитата: Кирилл от 01 сентября 2007, 13:51:36
Давно пора избавить HC от гадания на сигнатурах и временах создания.
А если кому-то надо извращаться с кешем на FAT32 - пусть отключает хранение заголовков в настройках.
Слишком много существующих и новых фич зависят от формируемых/хранимых HC заголовков! Отсутствие их поддержки в FAT32 будет накладывать серьезные ограничения на функциональность HC, вплоть до полной неработоспособности с этой файловой системой, что недопустимо!
Да, хранить заголовки ответов сервера желательно, но решение должно быть универсальным, особенно в силу грядущей многоплатформенности HC !
Сообщить модератору
Записан
Михаил
Gold beta tester
Репутация: +337/-14
Offline
Сообщений: 5513
Re: Размер экономии от кэширования зависит от даты в If-Modified-Since
«
Ответ #5 :
08 сентября 2007, 21:50:57 »
Все так. Сервер может повести себя по-разному. Но меня поразила тотальность, с которой большинство серверов не реагируют на IMS, отличную от Last-Modified. Реальный ущерб от этого велик и существенно сказывается на общей экономии.
Сообщить модератору
Записан
Михаил
Gold beta tester
Репутация: +337/-14
Offline
Сообщений: 5513
Re: Размер экономии от кэширования зависит о&
«
Ответ #6 :
17 ноября 2007, 11:48:35 »
Протестировал несколько произвольно взятых сайтов. Из 18 сайтов, возвращающих Last-Modified, 13 НЕ реагируют на вставленный НС If-Modified-Since, все равно возвращая полный ответ "200". Из них 2 не реагируют даже на IMS, совпадающий с LM.
Не бог весть какая презентабельная выборка, но, имхо, дает повод серьезно подумать над минимизацией наносимого ущерба.
Предлагаю сразу при получении заголовка ответа до передачи клиенту анализировать заголовок на предмет соответствия Last-Modified указанному в запросе If-Modified-Since. Если LM <= IMS, то:
- незамедлительно рвать соединение с сервером, отказываясь от получения ответа (если была очередь, то следующие запросы [пере]запрашивать у сервера в рамках нового соединения);
- в зависимости от того, чей был IMS, отдавать клиенту или ответ 304, или файл из кэша.
«
Последнее редактирование: 17 ноября 2007, 12:23:32 от Михаил
»
Сообщить модератору
Записан
Сергей
Beta tester
Репутация: +9/-2
Offline
Сообщений: 621
Re: Увеличение эффективности If-Modified-Since
«
Ответ #7 :
17 ноября 2007, 18:49:14 »
Разумная мысль
Поддерживаю.
Сообщить модератору
Записан
Михаил
Gold beta tester
Репутация: +337/-14
Offline
Сообщений: 5513
Re: Увеличение эффективности If-Modified-Since
«
Ответ #8 :
18 ноября 2007, 01:44:27 »
Есть мысль улучшить алгоритм выдачи ответа "304 (НС)".
Если получен запрос с "If-Modified-Since":
1. Проверяем список Т - если сработал, то наличие файла в кэше можно не проверять, а сразу ответить браузеру "304 (НС)". Стоп.
2. Инициализируем переменную MaxAge:=0. В ней в итоге будет содержаться самый большой из критериев свежести для строк списка Н, в которых сработает регэксп, но не сработает критерий свежести. Нужно для избежания повторного прохода списка Н.
3. Проверяем список Н. При этом на соответствие критерию свежести проверяем только IMS.
3а. Если в текущей строке списка Н сработал и регэксп, и критерий свежести, то отвечаем "304 (HC)". Стоп.
3б. Если в текущей строке списка Н сработал только регэксп, но не сработал критерий свежести, то MaxAge := max(MaxAge, КритерийСвежести).
4. Если файл в кэше есть и он свежий по критерию, указанному в MaxAge, то отдаем файл из кэша. Стоп.
5. Качаем ответ из интернета.
Преимущества подхода:
- исключена ошибка НС, описанная
здесь
;
- исключен недостаток при исправлении этой ошибки, описанный
здесь
;
- теперь при ответе "304 (HC)" проверка наличия файла в кэше вообще никогда не производится (а число таких ответов достаточно велико), т.е. исключается доступ к медленному диску/файловой системе;
- теперь экономящий ресурсы ответ "304 (НС)" будет даваться и для части URL'ов, подпадающих в списке Н под правила с критериями свежести, т.е. еще чаще.
Если КритерийСвежести задан в абсолютном виде (а востребовано ли это вообще в НС?), то это можно учесть в алгоритме тривиальным образом.
All
Гляньте, плиз, не совершил ли где логической ошибки.
«
Последнее редактирование: 18 ноября 2007, 02:43:19 от Михаил
»
Сообщить модератору
Записан
Михаил
Gold beta tester
Репутация: +337/-14
Offline
Сообщений: 5513
Re: Увеличение эффективности If-Modified-Since
«
Ответ #9 :
18 ноября 2007, 03:23:25 »
Пункт 5 лучше, имхо, сделать таким:
5. Качаем ответ из интернета. Если сработал список З и в списке Н срабатывал хоть в одной строке регэксп (без учета критерия свежести), то подменить в ответе сервера значение поля Last-Modified на Сейчас или добавить такое поле, если его нет.
Сообщить модератору
Записан
DenZzz
Модератор
Репутация: +179/-11
Offline
Сообщений: 5589
Re: Увеличение эффективности If-Modified-Since
«
Ответ #10 :
18 ноября 2007, 12:59:52 »
Цитата: Михаил от 18 ноября 2007, 03:23:25
5. Качаем ответ из интернета. Если сработал список З и в списке Н срабатывал хоть в одной строке регэксп (без учета критерия свежести), то подменить в ответе сервера значение поля Last-Modified на Сейчас или добавить такое поле, если его нет.
Допустим, зашли впервые на новый сайт (его нет в кэше браузера и HC). Чтобы выяснить, надо ли добавлять/править "Last-Modified", придется дополнительно проверить список Н, чего раньше делать было не нужно!
Если не править "Last-Modified", то при обновлении страницы велика вероятность, что он окажется просроченным и HC повторно выдаст файл из кэша.
Править "Last-Modified" всем файлам без разбору мы не можем...
И еще такая ситуация: IMS и дата файла просрочены по критерию свежести. HC шлет запрос с IMS в инет. Сервер отвечает "304". Сейчас HC просто передает этот ответ браузеру и обновляет дату файла в своем кэше, чтобы его "освежить" для следующих запросов.
По твоей логике придется повторно слать файл браузеру со свежим "Last-Modified", т.к. иначе IMS файла у браузера останется старым со всеми вытекающими...
«
Последнее редактирование: 18 ноября 2007, 13:07:39 от DenZzz
»
Сообщить модератору
Записан
Михаил
Gold beta tester
Репутация: +337/-14
Offline
Сообщений: 5513
Re: Увеличение эффективности If-Modified-Since
«
Ответ #11 :
19 ноября 2007, 19:02:54 »
Цитата: DenZzz от 18 ноября 2007, 12:59:52
Допустим, зашли впервые на новый сайт (его нет в кэше браузера и HC). Чтобы выяснить, надо ли добавлять/править "Last-Modified", придется дополнительно проверить список Н, чего раньше делать было не нужно!
Правильно. Надо будет проверить список Н.
Цитировать
Сейчас HC просто передает этот ответ браузеру и обновляет дату файла в своем кэше, чтобы его "освежить" для следующих запросов.
Если IMS свежее ДатыФайла, то обновление ДатыФайла может привести к выдаче неактуального контента при всех последующих запросах. В обычных условиях это маловероятный случай. Однако если мы хотим сохранить нормальную работоспособность при ручной правке кэша, временном переключении/отключении прокси, то эту ситуацию надо учитывать. Имхо, надо бы вставить проверку и не обновлять ДатуФайла при таком раскладе.
Цитировать
По твоей логике придется повторно слать файл браузеру со свежим "Last-Modified", т.к. иначе IMS файла у браузера останется старым со всеми вытекающими...
Отвечаем клиенту так же - "304". Если когда-нибудь потом будет повторный запрос, и файл в кэше клиента сохранится, и файл в кэше НС не успеет снова стать просроченным, то отдадим клиенту файл из кэша НС с новым Last-Modified.
PS О-о-о! С юбилейным тебя постом! Опять нет повода не выпить!
«
Последнее редактирование: 19 ноября 2007, 19:09:38 от Михаил
»
Сообщить модератору
Записан
DenZzz
Модератор
Репутация: +179/-11
Offline
Сообщений: 5589
Re: Увеличение эффективности If-Modified-Since
«
Ответ #12 :
19 ноября 2007, 21:40:54 »
Цитата: Михаил от 18 ноября 2007, 01:44:27
Преимущества подхода:
- исключена ошибка НС, описанная
здесь
;
- исключен недостаток при исправлении этой ошибки, описанный
здесь
;
- теперь при ответе "304 (HC)" проверка наличия файла в кэше вообще никогда не производится (а число таких ответов достаточно велико), т.е. исключается доступ к медленному диску/файловой системе;
- теперь экономящий ресурсы ответ "304 (НС)" будет даваться и для части URL'ов, подпадающих в списке Н под правила с критериями свежести, т.е. еще чаще.
Идея интересная, но как ты сам подтвердил, имеются накладные расходы:
- Надо будет проверять список Н для всех даже новых файлов.
- Иногда придется повторно отдавать клиенту неизменившиеся файлы из кэша НС с новым Last-Modified.
Оффтопик:
Цитировать
PS О-о-о! С юбилейным тебя постом! Опять нет повода не выпить!
Уже размочил счет!
Сообщить модератору
Записан
Михаил
Gold beta tester
Репутация: +337/-14
Offline
Сообщений: 5513
Re: Увеличение эффективности If-Modified-Since
«
Ответ #13 :
19 ноября 2007, 22:42:24 »
Перевесят ли привносимые преимущества появившиеся накладные расходы или наоборот (с точки зрения расходования ресурсов) - вопрос философский. Имхо, можно считать "по нулям". В остатке устранение бага.
Сообщить модератору
Записан
Михаил
Gold beta tester
Репутация: +337/-14
Offline
Сообщений: 5513
Возвращать 304 при запросе If-None-Match
«
Ответ #14 :
10 февраля 2008, 15:24:41 »
Никогда не обращал внимания, но сейчас случайно увидел. Бывает, что в ответе сервера присутствует ETag и нет Last-Modified (
http://feather.perl6.nl/syn/
). В следующий раз браузер запрашивает этот же УРЛ без IMS, но с If-None-Match. Если файл на сервере не изменился, то приходит ответ 304, и НС отдает файл из кэша. Однако НС мог бы точно так же ответить браузеру 304 Not Modified и не лезть в кэш.
Может возникнуть вопрос: ведь НС вставляет свой IMS и не может быть уверенности в том, на что именно отвечает "304" сервер - на If-None-Match браузера или на IMS НС. На этот вопрос ответ дает RFC 2616:
Цитировать
If none of the entity tags match, then the server MAY perform the
requested method as if the If-None-Match header field did not exist,
but MUST also ignore any If-Modified-Since header field(s) in the
request. That is, if no entity tags match, then the server MUST NOT
return a 304 (Not Modified) response.
Сообщить модератору
Записан
Rick
Администратор
Репутация: +15/-1
Offline
Сообщений: 868
Отдавать ли файл из кэша при 502 вместо 304?
«
Ответ #15 :
28 февраля 2008, 01:51:55 »
Дано: включена опция "Добавить If-Modified-Since при наличии файла в кэше", файл в кэше имеется, и выполняется запрос к серверу. Запрос завершается ошибкой.
Вопрос: передать клиенту (браузеру) ответ об ошибке или отдать имеющийся файл из кэша?
Сообщить модератору
Записан
DenZzz
Модератор
Репутация: +179/-11
Offline
Сообщений: 5589
Re: Отдавать ли файл из кэша при 502 вместо 304?
«
Ответ #16 :
28 февраля 2008, 15:40:46 »
Цитата: Rick от 28 февраля 2008, 01:51:55
Вопрос: передать клиенту (браузеру) ответ об ошибке или отдать имеющийся файл из кэша?
Без подтверждения сервером актуальности файла отдавать из кэша старый, имхо, неправильно. Это будет вводить в заблуждение относительно свежести данных и работоспособности сервера.
Если бы актуальность файла не была бы важна, то пользователь внес бы его в "Не обновлять" или включил "Автономный режим"...
Сообщить модератору
Записан
Михаил
Gold beta tester
Репутация: +337/-14
Offline
Сообщений: 5513
Re: Увеличение эффективности If-Modified-Since
«
Ответ #17 :
01 мая 2008, 23:05:09 »
Жаль, что в этом направлении тишина. Баг ведь остается.
Цитата: DenZzz от 19 ноября 2007, 21:40:54
имеются накладные расходы:
- Надо будет проверять список Н для всех даже новых файлов.
Добавлю, что НЕ надо будет как сейчас проверять список "П".
Сообщить модератору
Записан
Михаил
Gold beta tester
Репутация: +337/-14
Offline
Сообщений: 5513
Re: Увеличение эффективности If-Modified-Since
«
Ответ #18 :
15 мая 2008, 11:47:06 »
Жалко, что последнее предложение не реализуется. Попробую еще одно независимое от первого.
Сейчас если сервер шлет ответ 200 без Last-Modified, то НС переправляет его клиенту так же без LM. При повторном запросе того же контента клиент (по крайней мере, Опера) вставить If-Modified-Since не может, т.к. взять его неоткуда.
Предлагаю вставлять LM=Сейчас в такие ответы, тем самым эффективнее используя собстсвенный кэш клиента, сокращая расход ресурсов и уменьшая в ряде случаев трафик.
В чем польза:
- если файл попадает под список Н либо сервер отвечает 304, то сейчас файл тянется из кэша, а при новом раскладе будет отдаваться ответ 304 и к файловой системе обращений не будет;
- если отключена опция НС "Вставлять IMS" и файл на сервере не изменился, то сейчас файл тянется из сети, а по-новому сервером будет возвращаться 304.
Парадокс - падает отображаемый процент экономии, а сама экономия возрастет
«
Последнее редактирование: 15 мая 2008, 11:53:21 от Михаил
»
Сообщить модератору
Записан
mai62
Автор HC
Репутация: +226/-4
Offline
Сообщений: 6383
Re: Увеличение эффективности If-Modified-Since
«
Ответ #19 :
16 мая 2008, 20:38:50 »
Последнее предложение реализовать несложно. Если возражений нет, сделаю.
Про алгоритм из 5 пунктов: читал несколько раз, что-то наворочено всего много. Или сегодня плохо получается сосредоточиться.
Сообщить модератору
Записан
Михаил
Gold beta tester
Репутация: +337/-14
Offline
Сообщений: 5513
Re: Увеличение эффективности If-Modified-Since
«
Ответ #20 :
16 мая 2008, 21:13:13 »
Цитата: mai62 от 16 мая 2008, 20:38:50
Про алгоритм из 5 пунктов: читал несколько раз, что-то наворочено всего много.
Общая мысль - эффективнее использовать собственный кэш клиента. Если клиент шлет в запросе IMS, то сейчас НС это плохо использует - ищет файл в своем кэше и проверяет список Н сообразно дате этого файла. А можно в кэш не лезть, а проверять список "Н" по дате, указанной в IMS клиента.
Т.е. решение "Не обновлять" принимаем в отношении файла из кэша клиента, а не из кэша НС. Экономим на отсутствии обращений к файловой системе (поиск файла в кэше НС становится в подавляющем большинстве таких случаев ненужен). Если даже кэш на винчестере - это выигрыш, а когда на сетевом диске - БОЛЬШОЙ выигрыш.
Попутно устраняется баг с возможной выдачей пользователю неактуального контента.
«
Последнее редактирование: 16 мая 2008, 21:42:01 от Михаил
»
Сообщить модератору
Записан
Михаил
Gold beta tester
Репутация: +337/-14
Offline
Сообщений: 5513
Re: Увеличение эффективности If-Modified-Since
«
Ответ #21 :
12 июня 2008, 11:38:49 »
Теперь такой пример. НС использует два каталога кэша - локальный и сетевой (только для чтения).
1. Файл подпадает под список Н (правило с критерием свежести) и содержится в обоих кэшах. В локальном каталоге он устарел по критерию свежести, а на сетевом лежит свежий. Запрашиваем файл... И НС тянет его из интернет несмотря на наличие в кэше!
2. Файл лежит в обоих кэшах. В локальном устарел, а в сетевом свеж относительно файла на сервере. Запрашиваем... И взамен ответа сервера 304 и взятия из кэша снова тянется из инета весь файл!
Что делать с этим?
Итого по этой теме уже много накопилось мыслей. Помимо данного поста, это
http://handycache.ru/forum/index.php?topic=782.msg8401#msg8401
http://handycache.ru/forum/index.php?topic=782.msg8413#msg8413
http://handycache.ru/forum/index.php?topic=782.msg11857#msg11857
Сообщить модератору
Записан
mai62
Автор HC
Репутация: +226/-4
Offline
Сообщений: 6383
Re: Увеличение эффективности If-Modified-Since
«
Ответ #22 :
12 июня 2008, 11:48:26 »
Михаил
Я не считаю твои предложения в этой теме неправильными или ненужными. Причина задержки в том, что они требуют нетривиальных изменений (а может мне это только кажется с первого взгляда) и я пока не нашел времени этим заняться.
Спасибо за настойчивость.
Сообщить модератору
Записан
DenZzz
Модератор
Репутация: +179/-11
Offline
Сообщений: 5589
Re: Увеличение эффективности If-Modified-Since
«
Ответ #23 :
13 июня 2008, 15:01:16 »
Цитата: Михаил от 12 июня 2008, 11:38:49
Что делать с этим?
ИМХО, лучше второй раз скачать из инета, чем удваивать количество обращений к диску! Выяснение дат файлов на тормозном сетевом диске отнимет много времени, причем это время часто будет потрачено впустую...
Сообщить модератору
Записан
Михаил
Gold beta tester
Репутация: +337/-14
Offline
Сообщений: 5513
Re: Увеличение эффективности If-Modified-Since
«
Ответ #24 :
13 июня 2008, 16:14:33 »
В случае, описанном в п.1, однозначно нужно проверять второй кэш.
Цитировать
это время часто будет потрачено впустую
Это может иметь место только при ситуации из п.2. Часто или нет, зависит от конкретного наполнения кэшей, разницы в частоте записи в каждый из кэшей, тарифа интернет (повременка, помегабайтный), наличия ограничения объема интернет-трафика для пользователя, от того, какая скорость доступа ко второму кэшу (локальный, сетевой, флэш и др.). Имхо, правильно предоставить выбор пользователю, как поступать в этом случае.
Сообщить модератору
Записан
DenZzz
Модератор
Репутация: +179/-11
Offline
Сообщений: 5589
Re: Увеличение эффективности If-Modified-Since
«
Ответ #25 :
13 июня 2008, 16:25:46 »
Цитата: Михаил от 13 июня 2008, 16:14:33
Цитировать
это время часто будет потрачено впустую
Это может иметь место только при ситуации из п.2.
И в случае из п.1, когда файл в сетевом кэше также окажется просроченным - время на выяснение даты потратим, а качать придется из инета.
Сообщить модератору
Записан
Михаил
Gold beta tester
Репутация: +337/-14
Offline
Сообщений: 5513
Re: Увеличение эффективности If-Modified-Since
«
Ответ #26 :
13 июня 2008, 16:36:56 »
Цитата: DenZzz от 13 июня 2008, 16:25:46
И в случае из п.1, когда файл в сетевом кэше также окажется просроченным - время на выяснение даты потратим, а качать придется из инета.
Думаю, что необходимость этого уже охватывается нашим умыслом, когда мы назначаем второй кэш. Всякий файл, за которым по итогам анализа первого кэша уже однозначно надо лезть в интернет, проверяется на наличие во втором кэше. Так сказать, последний рубеж обороны.
Сообщить модератору
Записан
mai62
Автор HC
Репутация: +226/-4
Offline
Сообщений: 6383
Re: Увеличение эффективности If-Modified-Since
«
Ответ #27 :
22 июня 2008, 13:42:33 »
Просьба конструктивно обсудить эту проблему и дать согласованный алгоритм, чтобы я мог быстро это сделать.
Сообщить модератору
Записан
Дем
Постоялец
Репутация: +6/-3
Offline
Сообщений: 167
Re: Увеличение эффективности If-Modified-Since
«
Ответ #28 :
03 июля 2008, 13:25:10 »
алгоритм - проверяем файлы, используем более новый.
тут ещё один вопрос - может кому будет нужно обновить файл во втором кеше из первого.
А вообще, такие узкоцелевые вопросы проще поручить решать самому пользователю через скрипты
Сообщить модератору
Записан
Михаил
Gold beta tester
Репутация: +337/-14
Offline
Сообщений: 5513
Сообщать кэшу клиента о времени устаревания
«
Ответ #29 :
15 июля 2008, 01:01:33 »
Для повышения эффективности собственного кэша клиента в паре с НС предлагаю при срабатывании списка Не обновлять передавать клиенту заголовок Expires с датой устаревания файла по критерию свежести списка Н (1 год, если критерия нет).
Теперь клиент пришлет повторный запрос к НС только по истечении критерия свежести и не будет тратить время на промежуточные проверочные запросы к НС.
Такое поведение сделать опциональным.
Скриптом реализовывать не очень желательно.
Сообщить модератору
Записан
Дем
Постоялец
Репутация: +6/-3
Offline
Сообщений: 167
Re: Сообщать кэшу клиента о времени устаревания
«
Ответ #30 :
17 июля 2008, 11:19:05 »
Мало поможет. Потому как файл для отображения всё равно надо откуда-то взять, а кеш браузера большинство пользователей НС урезает до минимума.
Сообщить модератору
Записан
Михаил
Gold beta tester
Репутация: +337/-14
Offline
Сообщений: 5513
Re: Сообщать кэшу клиента о времени устарева&
«
Ответ #31 :
17 июля 2008, 15:02:27 »
Это существенно поможет тем, кто не урезает кэш клиента. Я не урезаю, т.к. скорость работы в интернете ценю больше экономии места на диске. Собственно, для повышения этой скорости ценой расходования дискового пространтсва и создан НС. Читал, есть и другие, поступающие так же. Диск у меня настолько огромен по отношению к планам его наполнения каким-либо софтом, медиа и пр., что вопрос об экономии 500 МБ под кэш браузера не встанет даже в отдаленной перспективе. А собственное время хочется экономить максимально.
По сути, реализовав это предложение мы можем заставить кэш браузера работать в соответствии с правилами НАШЕГО списка "Не обновлять". Средствами самого браузера это сделать невозможно.
«
Последнее редактирование: 17 июля 2008, 15:27:01 от Михаил
»
Сообщить модератору
Записан
Сергей
Beta tester
Репутация: +9/-2
Offline
Сообщений: 621
Re: Сообщать кэшу клиента о времени устаревания
«
Ответ #32 :
17 июля 2008, 21:08:58 »
Поддерживаю. Нет никакого смысла урезать кэш браузера. А вот помочь HC более эффективно взаимодействовать с браузером стоит.
Сообщить модератору
Записан
Михаил
Gold beta tester
Репутация: +337/-14
Offline
Сообщений: 5513
Re: Увеличение эффективности If-Modified-Since
«
Ответ #33 :
07 августа 2008, 10:24:20 »
Цитата: mai62 от 22 июня 2008, 13:42:33
Просьба конструктивно обсудить эту проблему и дать согласованный алгоритм, чтобы я мог быстро это сделать.
Вот все предложения по улучшению эффективности взаимодействия с кэшем клиента:
1. Если (Last-Modified ответа 200 сервера <= If-Modified-Since запроса НС к серверу), то:
- незамедлительно рвем соединение с сервером, отказываясь от получения ответа
- если IMS был от клиента, то возвращаем 304, если его вставлял НС, возвращаем файл из кэша.
2. Если пришел запрос с IMS, то:
- при проходе списка Н проверяем на соответствие критерию свежести не дату файла в кэше как сейчас, а этот IMS. Если соответствует, прерываем проверку списка Н и возвращаем 304
- если список Н не сработал, только тогда проверяем наличие файла в кэше и соответствие критериям свежести списка Н даты этого файла (для этого второй проход по списку Н не нужен). Если сработало, то отдаем файл из кэша как сейчас
- если по результатам двух предыдущих шагов список Н так и не сработал, хотя регэксп соответствовал (т.е. Н не сработал только из-за критерия свежести), то подменить в ответе сервера (даже если это 304) значение поля Last-Modified на Сейчас или добавить такое поле, если его нет
- если (сервер ответил 304) и (IMS клиента >= ДатыФайлаВКэше), то обновляем дату файла в кэше.
3. Если пришел запрос с If-None-Match, а сервер ответил 304, то всегда отдаем это 304 клиенту. В кэш за файлом не лезем.
4. Если пришел ответ 200 без Last-Modified и ETag, то в ответ добавляем LM=Сейчас.
Сообщить модератору
Записан
Михаил
Gold beta tester
Репутация: +337/-14
Offline
Сообщений: 5513
Re: Увеличение эффективности If-Modified-Since
«
Ответ #34 :
07 августа 2008, 14:03:30 »
Еще вот забыл:
5. При срабатывании списка Н передавать клиенту заголовок Expires с датой устаревания файла по критерию свежести списка Н (1 год, если критерия нет).
Такое поведение сделать опциональным.
Сообщить модератору
Записан
DenZzz
Модератор
Репутация: +179/-11
Offline
Сообщений: 5589
Re: Увеличение эффективности If-Modified-Since
«
Ответ #35 :
07 августа 2008, 16:14:50 »
Цитата: Михаил от 07 августа 2008, 10:24:20
- если список Н не сработал,
только тогда проверяем наличие файла в кэше
и соответствие критериям свежести списка Н даты этого файла (для этого второй проход по списку Н не нужен). Если сработало, то отдаем файл из кэша как сейчас
Эти данные у HC уже есть до проверки списка Н - они нужны для работы скриптов по заголовкам запросов. Надеюсь, HC их запоминает и второй раз за ними в кэш не лезет...
Цитировать
- если (сервер ответил 304) и (IMS клиента
>
= ДатыФайлаВКэше), то обновляем дату файла в кэше.
Тут ты знаком не ошибся?
Цитировать
4. Если пришел ответ 200 без Last-Modified и ETag, то в ответ добавляем LM=Сейчас.
При существенной рассинхронизации системного времени сервера HC с сервером в инете в сочетании с работой п.1 получим постоянное чтение файлов из кэша, т.е. фактически неотключаемый автономный режим. Поэтому надо включение п.1 делать опциональным.
Вот твой алгоритм с моими поправками:
1. Если (Last-Modified ответа 200 сервера <= If-Modified-Since запроса НС к серверу)
, то:
- незамедлительно рвем соединение с сервером, отказываясь от получения ответа
- если IMS был от клиента, то возвращаем 304, если его вставлял НС, возвращаем файл из кэша и обновляем его дату.
Такое поведение сделать опциональным (в INI).
2. Если от клиента пришел запрос с IMS, то:
- при проходе списка Н если RegExp сработал, проверяем на соответствие критерию свежести IMS клиента. Если соответствует, возвращаем 304.
- если IMS клиента просрочен, проверяем по критерию свежести дату файла в кэше. Если соответствует, то отдаем файл из кэша.
- если по результатам двух предыдущих шагов ответ клиенту не сформирован, то делаем запрос на сервер с IMS клиента и подменяем в ответе сервера (даже если это 304) значение поля Last-Modified на "Сейчас" или добавляем такое поле, если его нет
- если (сервер ответил 304) и (IMS клиента <= ДатыФайлаВКэше), то обновляем дату файла в кэше.
2а. Если от клиента пришел запрос без IMS и If-None-Match, то:
- проверяем по критерию свежести дату файла в кэше. Если соответствует, то отдаем файл из кэша
- иначе, вставляем свой IMS и делаем запрос на сервер
- если сервер ответил 304, то обновляем дату файла в кэше и передаем его клиенту, как и сейчас.
3. Если пришел запрос с If-None-Match
, то свой IMS не вставляем (по RFC 2616 его все равно сервер проигнорирует!). Если сервер ответил 304, то всегда отдаем это 304 клиенту. В кэш за файлом не лезем, дату не обновляем.
4. Если пришел ответ 200 без Last-Modified и ETag
, то в ответ добавляем LM=Сейчас.
5. При срабатывании списка Н
передаем клиенту заголовок Expires с датой устаревания файла по критерию свежести, если он положителен (1 год, если критерия нет или он отрицателен).
Такое поведение сделать опциональным (в INI).
Сообщить модератору
Записан
Михаил
Gold beta tester
Репутация: +337/-14
Offline
Сообщений: 5513
Re: Увеличение эффективности If-Modified-Since
«
Ответ #36 :
07 августа 2008, 18:35:31 »
Цитата: DenZzz от 07 августа 2008, 16:14:50
Эти данные у HC уже есть до проверки списка Н - они нужны для работы скриптов по заголовкам запросов. Надеюсь, HC их запоминает и второй раз за ними в кэш не лезет...
Скрипты запросов могут быть отключены/не быть прописаны. Есть у НС эти данные при таком расладе?
Цитировать
Тут ты знаком не ошибся?
Согласен.
Цитировать
При существенной рассинхронизации системного времени сервера HC с сервером в инете в сочетании с работой п.1 получим постоянное чтение файлов из кэша, т.е. фактически неотключаемый автономный режим. Поэтому надо включение п.1 делать опциональным.
Согласен.
Цитировать
2. Если от клиента пришел запрос с IMS, то:
- при проходе списка Н если RegExp сработал, проверяем на соответствие критерию свежести IMS клиента. Если соответствует, возвращаем 304.
- если IMS клиента просрочен, проверяем по критерию свежести дату файла в кэше. Если соответствует, то отдаем файл из кэша.
Если регэксп сработал, а IMS не соответствует критерию свежести, то не надо сразу проверять дату файла. Ведь могут сработать следующие правила. Надо полностью пройти
весь
список Н с IMS и только после того как все строки Н не сработали, но регэксп срабатывал, сделать одну проверку на соответствие даты файла в кэше. По ее результатам принять решение о выдаче файла из кэша.
Сообщить модератору
Записан
DenZzz
Модератор
Репутация: +179/-11
Offline
Сообщений: 5589
Re: Увеличение эффективности If-Modified-Since
«
Ответ #37 :
07 августа 2008, 19:13:51 »
Цитата: Михаил от 07 августа 2008, 18:35:31
Скрипты запросов могут быть отключены/не быть прописаны. Есть у НС эти данные при таком расладе?
Учитывая, сколько новых вкусностей несут в себе скрипты в плане экономии трафика/времени, управления пользователями, ограничением скорости и трафика и т.д., думаю скрипты будут включены у многих...
В какой момент HC собирает сейчас информацию о файлах в кэше при выключенных скриптах, я точно не знаю.
Цитата: Михаил от 07 августа 2008, 18:35:31
сделать одну проверку на соответствие даты файла в кэше. По ее результатам принять решение о выдаче файла из кэша.
Как минимум 2 проверки: отдельно для положительных и отрицательных критериев свежести. Чтобы повторный прогон по всему списку не делать, нужно запоминать максимальные значения критериев свежести у сработавших RegExp: отдельно для положительных и отрицательных.
Сообщить модератору
Записан
Михаил
Gold beta tester
Репутация: +337/-14
Offline
Сообщений: 5513
Re: Увеличение эффективности кэша клиента (I-M-S, I
«
Ответ #38 :
22 ноября 2008, 09:22:13 »
п.4 лучше сделать так: Если пришел ответ 200 без Last-Modified и ETag, то в ответ добавляем LM=поле Date ответа. Тогда рассинхронизации по времени нет. Если Date нет (это бывает редко), то LM=Сейчас.
Не забыть надо и про
это
.
Сообщить модератору
Записан
mai62
Автор HC
Репутация: +226/-4
Offline
Сообщений: 6383
Re: Увеличение эффективности кэша клиента (I-M-S, I-N-M, Expires и т.п.)
«
Ответ #39 :
13 июля 2009, 00:43:20 »
Цитировать
1. Если (Last-Modified ответа 200 сервера <= If-Modified-Since запроса НС к серверу), то:
- незамедлительно рвем соединение с сервером, отказываясь от получения ответа
- если IMS был от клиента, то возвращаем 304, если его вставлял НС, возвращаем файл из кэша.
Разве сервер может ответить 200, если (Last-Modified ответа 200 сервера <= If-Modified-Since запроса НС к серверу)?
Он ведь ответит 304.
Сообщить модератору
Записан
Михаил
Gold beta tester
Репутация: +337/-14
Offline
Сообщений: 5513
Re: Увеличение эффективности кэша клиента (I-M-S, I-N-M, Expires и т.п.)
«
Ответ #40 :
13 июля 2009, 07:16:14 »
Цитировать
Разве сервер может ответить 200, если (Last-Modified ответа 200 сервера <= If-Modified-Since запроса НС к серверу)?
Да. Так очень часто и происходит (см. первый пост этого топика).
Сообщить модератору
Записан
DenZzz
Модератор
Репутация: +179/-11
Offline
Сообщений: 5589
Re: Увеличение эффективности кэша клиента (I-M-S, I-N-M, Expires и т.п.)
«
Ответ #41 :
29 сентября 2009, 13:15:42 »
И еще про эффективность кэша браузера и снижения нагрузки на диск с кэшем HC.
Когда в запросе есть заголовок If-None-Match, а в списке Н есть правило без критерия свежести, зачем вообще HC ищет файл на диске? Почему бы сразу не ответить 304 ?
Пункт 3
алгоритма
предлагаю изложить в следующей редакции:
3. Если пришел запрос с If-None-Match:
- проверяем в списке Н правила без критерия свежести. Если сработало, то сразу отвечаем 304, в кэше файл не ищем.
- проверяем в списке Н правила с критерием свежести. Если сработало, проверяем по критерию свежести дату файла в кэше. Если соответствует, то отдаем файл из кэша.
- если список Н не сработал, то свой IMS не вставляем (по RFC 2616 его все равно сервер проигнорирует!). Если сервер ответил 304, то всегда отдаем это 304 клиенту. В кэш за файлом не лезем, дату не обновляем.
Добавлено: 29 Сентября 2009, 13:24:52
И еще один момент: когда в запросе есть If-Modified-Since или If-None-Match и сработал список Т, то сразу отвечаем 304, в кэше файл не ищем.
Сообщить модератору
Записан
Nike
Новичок
Репутация: +2/-0
Offline
Сообщений: 19
Re: Увеличение эффективности кэша клиента (I-M-S, I-N-M, Expires и т.п.)
«
Ответ #42 :
15 октября 2009, 19:44:06 »
я конечно дико извиняюсь, но в какую именно секцию handycache.ini нужно это добавлять? Там таких параметров нет, нигде не написано. И ещё, можно такие "твики" куда-то в одно, пусть и сильно спрятанное место вынести?
Сообщить модератору
Записан
mai62
Автор HC
Репутация: +226/-4
Offline
Сообщений: 6383
Re: Увеличение эффективности кэша клиента (I-M-S, I-N-M, Expires и т.п.)
«
Ответ #43 :
15 октября 2009, 20:06:03 »
Все "твики" добавляются в секцию [TMainForm].
Вот список "твиков" (в скобках значения по умолчанию)
Работа регулярных выражений
- LimitRecursion (1000)
- MatchLimit (100000000)
Таймауты
- ConnectTimeOut (2000)
- ReadTimeOut (500)
"твики", реализующие предложения в этой теме (не доделано)
SendExpiresHeaderField (False)
StopDownloadingOldFiles (False)
Запрет чтения файлов вне папки кэша
ReadOnlyFromCachePath (True)
IP сетевого адаптера для доступа в инет
NetDevIP_Text
Задержка появления хинта в мониторе
TreeHintDelay (200)
Доступность отладочного лога
DebugModeVisible (False)
«
Последнее редактирование: 15 октября 2009, 20:10:45 от mai62
»
Сообщить модератору
Записан
Доктор ТуамОсес
Гость
Re: Увеличение эффективности кэша клиента (I-M-S, I-N-M, Expires и т.п.)
«
Ответ #44 :
28 мая 2011, 18:10:34 »
Уважаемые Господа
(и дамы, если таковые есть
) !
Не могли бы вы мне резюмировать то, к чему же вы в итоге этого интересного и захватывающего обсуждения пришли?
Объясните тупому "на пальцах":
как мне всё-таки HC настроить (где какие галки поставить/снять, что прописать в ini-файле) так, чтобы чтобы он "тянул" из инета файлы только в случае, если они реально изменились на серваке?
Сразу замечу
, что мне
{в отличии от некоторых уважаемых господ, которым проще, быстрей и удобней файл из инета вытянуть, чем грузить хард "напрасной" (с их точки зрения) работой}
харда ничуть не жалко: пускай HC колбасит его "как тузик грелку". Также я не боюсь "повышенной нагрузки на процессор" (на то он и процессор, чтобы "процессить").
Может я покажусь большим оригиналом (в наше-то время
Во время 100 мегабитных анлимов
), но мне трафика жалко больше, чем хард и проц вместе взятые.
И даже не трафика, а своего зря потраченного времени.
Ибо я "сижу" на Джей Эп Эр Эсе.
И порой GPRS соединение у меня "подвисает" так, что средняя скорость закачки у меня падает до 50 байт в секунду.
Поэтому если по делу/не по делу я буду каждый раз "тянуть" файлы из инета, то много времени потрачу впустую на ожидание "когда же млин оно загрузится?"
Просто в этой теме много самой противоречивой информации. Поэтому в голове у меня после прочтения этой темы образовалась "каша". Я так и не понял:
что конкретно нужно сделать, чтобы по максимуму избежать загрузки файлов, которые у меня есть уже в кэше и которые не менялись на серваке в инете.
Добавлено: 28 Мая 2011, 17:47:15
Цитата: mai62 от 15 октября 2009, 20:06:03
бла-бла-бла
- ReadTimeOut (500)
бла-бла-бла
Это то, о чём я думаю и о чём мечтал
ТУТ
?
Да?
Я имею ввиду пункт 4.
Добавлено: 28 Мая 2011, 18:07:07
Цитата: mai62 от 15 октября 2009, 20:06:03
Задержка появления хинта в мониторе
TreeHintDelay (200)
А это
"что за зверь такой"
(с)?
Это типа время, спустя которое, URL из нижней половине монитора отображается и в верхней?
Сообщить модератору
Записан
Доктор ТуамОсес
Гость
Re: Увеличение эффективности кэша клиента (I-M-S, I-N-M, Expires и т.п.)
«
Ответ #45 :
20 июля 2011, 17:01:13 »
Ну так что?
Ответов не будет? :
Или мне, как в известной пословице подождать 3 года?
Сообщить модератору
Записан
Доктор ТуамОсес
Гость
Re: Увеличение эффективности кэша клиента (I-M-S, I-N-M, Expires и т.п.)
«
Ответ #46 :
01 сентября 2011, 23:22:21 »
Цитата: mai62 от 15 октября 2009, 20:06:03
Все "твики" добавляются в секцию [TMainForm].
Вот список "твиков" (в скобках значения по умолчанию)
Работа регулярных выражений
- LimitRecursion (1000)
- MatchLimit (100000000)
Таймауты
- ConnectTimeOut (2000)
- ReadTimeOut (500)
"твики", реализующие предложения в этой теме (не доделано)
SendExpiresHeaderField (False)
StopDownloadingOldFiles (False)
Запрет чтения файлов вне папки кэша
ReadOnlyFromCachePath (True)
IP сетевого адаптера для доступа в инет
NetDevIP_Text
Задержка появления хинта в мониторе
TreeHintDelay (200)
Доступность отладочного лога
DebugModeVisible (False)
mai62!
Ну так расскажете наконец?
Или "обещанного 3 года ждут"?
В частности хотелось бы знать как завязаны ConnectTimeOut и ReadTimeOut с параметрами, указанными на вкладке <управление загрузкой>
Сообщить модератору
Записан
mai62
Автор HC
Репутация: +226/-4
Offline
Сообщений: 6383
Re: Увеличение эффективности кэша клиента (I-M-S, I-N-M, Expires и т.п.)
«
Ответ #47 :
02 сентября 2011, 11:14:21 »
Доктор ТуамОсес
Все, что можно было Вам уже сообщили. Читайте документацию и форум. Развлекать Вас разговорами я не имею возможности.
Сообщить модератору
Записан
Доктор ТуамОсес
Гость
Re: Увеличение эффективности кэша клиента (I-M-S, I-N-M, Expires и т.п.)
«
Ответ #48 :
02 сентября 2011, 13:26:56 »
Причём тут "развлекать разговорами"!?
Просто если уж ты реализовываешь какие-то фичи, то будь любезен описывать их
В HELP-е
.
А то у тебя прога имеют версии от 2011 года, а HELP датирован аж 2006-м годом
А то получается фичи-то ты сделал, а для чего они нужны? Как их использовать? Как они связаны с ранее реализованными? Не понятно. А телепаты все в отпуске.
Тогда нафига их делать если юзверь всё равно не сможет их заюзать, потому что не знает для чего они нужны и на что влияют.
Добавлено: 02 Сентября 2011, 13:19:42
Или ты как любой прогер не любишь писать доки на свои проги?
Я тебя понимаю: сам люблю больше проги писать, чем доки на них.
Просто, понимаешь, если нет нормальной документации на прогу, то её ценность сразу падает на порядки.
Ибо как смысл юзать "вещь в себе"?
Дай мне ссылку на полный хэлп к HC от 2011 года.
Или такого нет?
Сообщить модератору
Записан
stealzy
Пользователь
Репутация: +1/-2
Offline
Сообщений: 52
Re: Увеличение эффективности кэша клиента (I-M-S, I-N-M, Expires и т.п.)
«
Ответ #49 :
01 февраля 2015, 03:55:41 »
Добавил в секцию TMainForm
SendExpiresHeaderField=True
StopDownloadingOldFiles=True
Изменений не заметил.
Неменяющийся html скачивается заново, на этом форуме, в частности.
If-Modified-Since, Останавливать загрузку старых файлов — галки стоят.
Сообщить модератору
Записан
HC 1.0.0.551
Страниц:
1
2
3
[
Все
]
Вверх
Отправить эту тему
Печать
« предыдущая тема
следующая тема »
Перейти в:
Пожалуйста, выберите назначение:
-----------------------------
Главная категория
-----------------------------
=> Общие вопросы
=> Новые предложения
=> Дополнения, плагины
=> Сжатие трафика
=> English forum
=> Indonesian forum
-----------------------------
Гостевая
-----------------------------
=> Гостевая
-----------------------------
Дела домашние
-----------------------------
=> Сайт и форум HandyCache
=> Курилка
© 2006-2014 HandyCache Team. Все права защищены.
Загружается...