Страниц: 1 2 3 [Все]   Вниз
  Отправить эту тему    Печать  
Автор Тема: Увеличение эффективности кэша клиента (I-M-S, I-N-M, Expires и т.п.)  (Прочитано 44359 раз)
0 Пользователей и 1 Гость смотрят эту тему.
Михаил
Gold beta tester
*****

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

Сообщений: 5513



« : 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 Offline

Сообщений: 124


« Ответ #1 : 01 сентября 2007, 12:13:01 »

А что тут удивляться?
Не зря в HTTP 1.1 этот параметр назвали уже E-Tag - ибо время требует реализации глобальных часов и т.п. и т.д., а нам нужна лишь контрольная сумма для проверки измененности объекта.
Еще один (и очень весомый) довод в пользу хранения заголовков в кеше.
Сообщить модератору   Записан
Михаил
Gold beta tester
*****

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

Сообщений: 5513



« Ответ #2 : 01 сентября 2007, 13:13:30 »

А что тут удивляться?
Получается, что на практике название заголовка чаще всего не соответствует действительности. Его б тогда назвать "IfLastModified=".
Честно говоря, ужаснулся - у меня на этом теряется уйма возможной экономии. Ведь постоянно тянутся из сети html-ы по 50-200 КБ, которые должны были б просто браться из кэша.
Сообщить модератору   Записан
Кирилл
Beta tester
*****

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

Сообщений: 124


« Ответ #3 : 01 сентября 2007, 13:51:36 »

Получается, что на практике название заголовка чаще всего не соответствует действительности. Его б тогда назвать "IfLastModified=".
Честно говоря, ужаснулся - у меня на этом теряется уйма возможной экономии. Ведь постоянно тянутся из сети html-ы по 50-200 КБ, которые должны были б просто браться из кэша.
Дело не в названии заголовка - дело в реализации HTTP-сервера. Поскольку кеширующие браузеры и так хранят LastModified, следовательно именно его они и вставят при следующем запросе. Отсюда и оптимизация на сервере - можно вместо разбора строки в заголовке просто сравнить ее с оригинальной.
Давно пора избавить HC от гадания на сигнатурах и временах создания.
А если кому-то надо извращаться с кешем на FAT32 - пусть отключает хранение заголовков в настройках.
Сообщить модератору   Записан
DenZzz
Модератор
*****

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

Сообщений: 5589



« Ответ #4 : 08 сентября 2007, 21:44:30 »

Недавно с удивлением обнаружил, что многие серверы отвечают на If-Modified-Since "304 Not Modified", только если дата в IMS точно совпадает с датой Last-Modified!

Я наблюдал ситуацию, когда сервер вообще игнорировал "If-Modified-Since", видимо ожидая присутствия "If-None-Match", о чем я уже писал вот здесь!

Но и это не панацея! Например, вот здесь был пример, когда сервер по непонятной причине игнорировал совершенно правильные заголовки "I-M-S" и "I-N-M" !

Давно пора избавить HC от гадания на сигнатурах и временах создания.
А если кому-то надо извращаться с кешем на FAT32 - пусть отключает хранение заголовков в настройках.

Слишком много существующих и новых фич зависят от формируемых/хранимых HC заголовков! Отсутствие их поддержки в FAT32 будет накладывать серьезные ограничения на функциональность HC, вплоть до полной неработоспособности с этой файловой системой, что недопустимо!
Да, хранить заголовки ответов сервера желательно, но решение должно быть универсальным, особенно в силу грядущей многоплатформенности HC !
Сообщить модератору   Записан
Михаил
Gold beta tester
*****

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

Сообщений: 5513



« Ответ #5 : 08 сентября 2007, 21:50:57 »

Все так. Сервер может повести себя по-разному. Но меня поразила тотальность, с которой большинство серверов не реагируют на IMS, отличную от Last-Modified. Реальный ущерб от этого велик и существенно сказывается на общей экономии.
Сообщить модератору   Записан
Михаил
Gold beta tester
*****

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

Сообщений: 5513



« Ответ #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 Offline

Сообщений: 621



« Ответ #7 : 17 ноября 2007, 18:49:14 »

Разумная мысль Улыбка Поддерживаю.
Сообщить модератору   Записан
Михаил
Gold beta tester
*****

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

Сообщений: 5513



« Ответ #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 Offline

Сообщений: 5513



« Ответ #9 : 18 ноября 2007, 03:23:25 »

Пункт 5 лучше, имхо, сделать таким:
5. Качаем ответ из интернета. Если сработал список З и в списке Н срабатывал хоть в одной строке регэксп (без учета критерия свежести), то подменить в ответе сервера значение поля Last-Modified на Сейчас или добавить такое поле, если его нет.
Сообщить модератору   Записан
DenZzz
Модератор
*****

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

Сообщений: 5589



« Ответ #10 : 18 ноября 2007, 12:59:52 »

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 Offline

Сообщений: 5513



« Ответ #11 : 19 ноября 2007, 19:02:54 »

Допустим, зашли впервые на новый сайт (его нет в кэше браузера и HC). Чтобы выяснить, надо ли добавлять/править "Last-Modified", придется дополнительно проверить список Н, чего раньше делать было не нужно!
Правильно. Надо будет проверить список Н.
Цитировать
Сейчас HC просто передает этот ответ браузеру и обновляет дату файла в своем кэше, чтобы его "освежить" для следующих запросов.
Если IMS свежее ДатыФайла, то обновление ДатыФайла может привести к выдаче неактуального контента при всех последующих запросах. В обычных условиях это маловероятный случай. Однако если мы хотим сохранить нормальную работоспособность при ручной правке кэша, временном переключении/отключении прокси, то эту ситуацию надо учитывать. Имхо, надо бы вставить проверку и не обновлять ДатуФайла при таком раскладе.
Цитировать
По твоей логике придется повторно слать файл браузеру со свежим "Last-Modified", т.к. иначе IMS файла у браузера останется старым со всеми вытекающими...
Отвечаем клиенту так же - "304". Если когда-нибудь потом будет повторный запрос, и файл в кэше клиента сохранится, и файл в кэше НС не успеет снова стать просроченным, то отдадим клиенту файл из кэша НС с новым Last-Modified.

PS О-о-о! С юбилейным тебя постом! Опять нет повода не выпить! Улыбка
« Последнее редактирование: 19 ноября 2007, 19:09:38 от Михаил » Сообщить модератору   Записан
DenZzz
Модератор
*****

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

Сообщений: 5589



« Ответ #12 : 19 ноября 2007, 21:40:54 »

Преимущества подхода:
- исключена ошибка НС, описанная здесь;
- исключен недостаток при исправлении этой ошибки, описанный здесь;
- теперь при ответе "304 (HC)" проверка наличия файла в кэше вообще никогда не производится (а число таких ответов достаточно велико), т.е. исключается доступ к медленному диску/файловой системе;
- теперь экономящий ресурсы ответ "304 (НС)" будет даваться и для части URL'ов, подпадающих в списке Н под правила с критериями свежести, т.е. еще чаще.

Идея интересная, но как ты сам подтвердил, имеются накладные расходы:
- Надо будет проверять список Н для всех даже новых файлов.
- Иногда придется повторно отдавать клиенту неизменившиеся файлы из кэша НС с новым Last-Modified.

Оффтопик:
Цитировать
PS О-о-о! С юбилейным тебя постом! Опять нет повода не выпить!
Уже размочил счет! Улыбка
Сообщить модератору   Записан
Михаил
Gold beta tester
*****

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

Сообщений: 5513



« Ответ #13 : 19 ноября 2007, 22:42:24 »

Перевесят ли привносимые преимущества появившиеся накладные расходы или наоборот (с точки зрения расходования ресурсов) - вопрос философский. Имхо, можно считать "по нулям". В остатке устранение бага.
Сообщить модератору   Записан
Михаил
Gold beta tester
*****

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

Сообщений: 5513



« Ответ #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 Offline

Сообщений: 868


WWW
« Ответ #15 : 28 февраля 2008, 01:51:55 »

Дано: включена опция "Добавить If-Modified-Since при наличии файла в кэше", файл в кэше имеется, и выполняется запрос к серверу. Запрос завершается ошибкой.
Вопрос: передать клиенту (браузеру) ответ об ошибке или отдать имеющийся файл из кэша?
Сообщить модератору   Записан
DenZzz
Модератор
*****

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

Сообщений: 5589



« Ответ #16 : 28 февраля 2008, 15:40:46 »

Вопрос: передать клиенту (браузеру) ответ об ошибке или отдать имеющийся файл из кэша?

Без подтверждения сервером актуальности файла отдавать из кэша старый, имхо, неправильно. Это будет вводить в заблуждение относительно свежести данных и работоспособности сервера.
Если бы актуальность файла не была бы важна, то пользователь внес бы его в "Не обновлять" или включил "Автономный режим"...
Сообщить модератору   Записан
Михаил
Gold beta tester
*****

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

Сообщений: 5513



« Ответ #17 : 01 мая 2008, 23:05:09 »

Жаль, что в этом направлении тишина. Баг ведь остается.
имеются накладные расходы:
- Надо будет проверять список Н для всех даже новых файлов.
Добавлю, что НЕ надо будет как сейчас проверять список "П".
Сообщить модератору   Записан
Михаил
Gold beta tester
*****

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

Сообщений: 5513



« Ответ #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 Offline

Сообщений: 6383


« Ответ #19 : 16 мая 2008, 20:38:50 »

Последнее предложение реализовать несложно. Если возражений нет, сделаю.
Про алгоритм из 5 пунктов: читал несколько раз, что-то наворочено всего много. Или сегодня плохо получается сосредоточиться.
Сообщить модератору   Записан
Михаил
Gold beta tester
*****

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

Сообщений: 5513



« Ответ #20 : 16 мая 2008, 21:13:13 »

Про алгоритм из 5 пунктов: читал несколько раз, что-то наворочено всего много.
Общая мысль - эффективнее использовать собственный кэш клиента. Если клиент шлет в запросе IMS, то сейчас НС это плохо использует - ищет файл в своем кэше и проверяет список Н сообразно дате этого файла. А можно в кэш не лезть, а проверять список "Н" по дате, указанной в IMS клиента.
Т.е. решение "Не обновлять" принимаем в отношении файла из кэша клиента, а не из кэша НС. Экономим на отсутствии обращений к файловой системе (поиск файла в кэше НС становится в подавляющем большинстве таких случаев ненужен). Если даже кэш на винчестере - это выигрыш, а когда на сетевом диске - БОЛЬШОЙ выигрыш.
Попутно устраняется баг с возможной выдачей пользователю неактуального контента.
« Последнее редактирование: 16 мая 2008, 21:42:01 от Михаил » Сообщить модератору   Записан
Михаил
Gold beta tester
*****

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

Сообщений: 5513



« Ответ #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 Offline

Сообщений: 6383


« Ответ #22 : 12 июня 2008, 11:48:26 »

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

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

Сообщений: 5589



« Ответ #23 : 13 июня 2008, 15:01:16 »

Что делать с этим?

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

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

Сообщений: 5513



« Ответ #24 : 13 июня 2008, 16:14:33 »

В случае, описанном в п.1, однозначно нужно проверять второй кэш.
Цитировать
это время часто будет потрачено впустую
Это может иметь место только при ситуации из п.2. Часто или нет, зависит от конкретного наполнения кэшей, разницы в частоте записи в каждый из кэшей, тарифа интернет (повременка, помегабайтный), наличия ограничения объема интернет-трафика для пользователя, от того, какая скорость доступа ко второму кэшу (локальный, сетевой, флэш и др.). Имхо, правильно предоставить выбор пользователю, как поступать в этом случае.
Сообщить модератору   Записан
DenZzz
Модератор
*****

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

Сообщений: 5589



« Ответ #25 : 13 июня 2008, 16:25:46 »

Цитировать
это время часто будет потрачено впустую
Это может иметь место только при ситуации из п.2.

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

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

Сообщений: 5513



« Ответ #26 : 13 июня 2008, 16:36:56 »

И в случае из п.1, когда файл в сетевом кэше также окажется просроченным - время на выяснение даты потратим, а качать придется из инета.
Думаю, что необходимость этого уже охватывается нашим умыслом, когда мы назначаем второй кэш. Всякий файл, за которым по итогам анализа первого кэша уже однозначно надо лезть в интернет, проверяется на наличие во втором кэше. Так сказать, последний рубеж обороны.
Сообщить модератору   Записан
mai62
Автор HC
*****

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

Сообщений: 6383


« Ответ #27 : 22 июня 2008, 13:42:33 »

Просьба конструктивно обсудить эту проблему и дать согласованный алгоритм, чтобы я мог быстро это сделать.
Сообщить модератору   Записан
Дем
Постоялец
***

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

Сообщений: 167



« Ответ #28 : 03 июля 2008, 13:25:10 »

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

А вообще, такие узкоцелевые вопросы проще поручить решать самому пользователю через скрипты Улыбка
Сообщить модератору   Записан
Михаил
Gold beta tester
*****

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

Сообщений: 5513



« Ответ #29 : 15 июля 2008, 01:01:33 »

Для повышения эффективности собственного кэша клиента в паре с НС предлагаю при срабатывании списка Не обновлять передавать клиенту заголовок Expires с датой устаревания файла по критерию свежести списка Н (1 год, если критерия нет).
Теперь клиент пришлет повторный запрос к НС только по истечении критерия свежести и не будет тратить время на промежуточные проверочные запросы к НС.
Такое поведение сделать опциональным.
Скриптом реализовывать не очень желательно.
Сообщить модератору   Записан
Дем
Постоялец
***

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

Сообщений: 167



« Ответ #30 : 17 июля 2008, 11:19:05 »

Мало поможет. Потому как файл для отображения всё равно надо откуда-то взять, а кеш браузера большинство пользователей НС урезает до минимума.
Сообщить модератору   Записан
Михаил
Gold beta tester
*****

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

Сообщений: 5513



« Ответ #31 : 17 июля 2008, 15:02:27 »

Это существенно поможет тем, кто не урезает кэш клиента. Я не урезаю, т.к. скорость работы в интернете ценю больше экономии места на диске. Собственно, для повышения этой скорости ценой расходования дискового пространтсва и создан НС. Читал, есть и другие, поступающие так же. Диск у меня настолько огромен по отношению к планам его наполнения каким-либо софтом, медиа и пр., что вопрос об экономии 500 МБ под кэш браузера не встанет даже в отдаленной перспективе. А собственное время хочется экономить максимально.

По сути, реализовав это предложение мы можем заставить кэш браузера работать в соответствии с правилами НАШЕГО списка "Не обновлять". Средствами самого браузера это сделать невозможно.
« Последнее редактирование: 17 июля 2008, 15:27:01 от Михаил » Сообщить модератору   Записан
Сергей
Beta tester
*****

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

Сообщений: 621



« Ответ #32 : 17 июля 2008, 21:08:58 »

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

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

Сообщений: 5513



« Ответ #33 : 07 августа 2008, 10:24:20 »

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

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 Offline

Сообщений: 5513



« Ответ #34 : 07 августа 2008, 14:03:30 »

Еще вот забыл:

5. При срабатывании списка Н передавать клиенту заголовок Expires с датой устаревания файла по критерию свежести списка Н (1 год, если критерия нет).
Такое поведение сделать опциональным.
Сообщить модератору   Записан
DenZzz
Модератор
*****

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

Сообщений: 5589



« Ответ #35 : 07 августа 2008, 16:14:50 »

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

Эти данные у 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 Offline

Сообщений: 5513



« Ответ #36 : 07 августа 2008, 18:35:31 »

Эти данные у HC уже есть до проверки списка Н - они нужны для работы скриптов по заголовкам запросов. Надеюсь, HC их запоминает и второй раз за ними в кэш не лезет...
Скрипты запросов могут быть отключены/не быть прописаны. Есть у НС эти данные при таком расладе?
Цитировать
Тут ты знаком не ошибся?
Согласен.
Цитировать
При существенной рассинхронизации системного времени сервера HC с сервером в инете в сочетании с работой п.1 получим постоянное чтение файлов из кэша, т.е. фактически неотключаемый автономный режим. Поэтому надо включение п.1 делать опциональным.
Согласен.
Цитировать
2. Если от клиента пришел запрос с IMS, то:
- при проходе списка Н если RegExp сработал, проверяем на соответствие критерию свежести IMS клиента. Если соответствует, возвращаем 304.
- если IMS клиента просрочен,  проверяем по критерию свежести дату файла в кэше. Если соответствует, то отдаем файл из кэша.
Если регэксп сработал, а IMS не соответствует критерию свежести, то не надо сразу проверять дату файла. Ведь могут сработать следующие правила. Надо полностью пройти весь список Н с IMS и только после того как все строки Н не сработали, но регэксп срабатывал, сделать одну проверку на соответствие даты файла в кэше. По ее результатам принять решение о выдаче файла из кэша.
Сообщить модератору   Записан
DenZzz
Модератор
*****

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

Сообщений: 5589



« Ответ #37 : 07 августа 2008, 19:13:51 »

Скрипты запросов могут быть отключены/не быть прописаны. Есть у НС эти данные при таком расладе?

Учитывая, сколько новых вкусностей несут в себе скрипты в плане экономии трафика/времени, управления пользователями, ограничением скорости и трафика и т.д., думаю скрипты будут включены у многих... Подмигивающий
В какой момент HC собирает сейчас информацию о файлах в кэше при выключенных скриптах, я точно не знаю.

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

Как минимум 2 проверки: отдельно для положительных и отрицательных критериев свежести. Чтобы повторный прогон по всему списку не делать, нужно запоминать максимальные значения критериев свежести у сработавших RegExp: отдельно для положительных и отрицательных.


Сообщить модератору   Записан
Михаил
Gold beta tester
*****

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

Сообщений: 5513



« Ответ #38 : 22 ноября 2008, 09:22:13 »

п.4 лучше сделать так: Если пришел ответ 200 без Last-Modified и ETag, то в ответ добавляем LM=поле Date ответа. Тогда рассинхронизации по времени нет. Если Date нет (это бывает редко), то LM=Сейчас.

Не забыть надо и про это.
Сообщить модератору   Записан
mai62
Автор HC
*****

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

Сообщений: 6383


« Ответ #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 Offline

Сообщений: 5513



« Ответ #40 : 13 июля 2009, 07:16:14 »

Цитировать
Разве сервер может ответить 200, если (Last-Modified ответа 200 сервера <= If-Modified-Since запроса НС к серверу)?
Да. Так очень часто и происходит (см. первый пост этого топика).
Сообщить модератору   Записан
DenZzz
Модератор
*****

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

Сообщений: 5589



« Ответ #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 Offline

Сообщений: 19


« Ответ #42 : 15 октября 2009, 19:44:06 »

я конечно дико извиняюсь, но в какую именно секцию handycache.ini нужно это добавлять? Там таких параметров нет, нигде не написано. И ещё, можно такие "твики" куда-то в одно, пусть и сильно спрятанное место вынести?
Сообщить модератору   Записан
mai62
Автор HC
*****

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

Сообщений: 6383


« Ответ #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 » Сообщить модератору   Записан
Доктор ТуамОсес
Гость
« Ответ #44 : 28 мая 2011, 18:10:34 »

Уважаемые Господа (и дамы, если таковые есть Улыбка ) !
Не могли бы вы мне резюмировать то, к чему же вы в итоге этого интересного и захватывающего обсуждения пришли? Смущен

Объясните тупому "на пальцах": как мне всё-таки HC настроить (где какие галки поставить/снять, что прописать в ini-файле) так, чтобы чтобы он "тянул" из инета файлы только в случае, если они реально изменились на серваке? Непонимаю

Сразу замечу, что мне {в отличии от некоторых уважаемых господ, которым проще, быстрей и удобней файл из инета вытянуть, чем грузить хард "напрасной" (с их точки зрения) работой} харда ничуть не жалко: пускай HC колбасит его "как тузик грелку". Также я не боюсь "повышенной нагрузки на процессор" (на то он и процессор, чтобы "процессить").

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

И даже не трафика, а своего зря потраченного времени.

Ибо я "сижу" на Джей Эп Эр Эсе.

И порой GPRS соединение у меня "подвисает" так, что средняя скорость закачки у меня падает до 50 байт в секунду. Благодарю

Поэтому если по делу/не по делу я буду каждый раз "тянуть" файлы из инета, то много времени потрачу впустую на ожидание "когда же млин оно загрузится?"

Просто в этой теме много самой противоречивой информации. Поэтому в голове у меня после прочтения этой темы образовалась "каша". Я так и не понял: что конкретно нужно сделать, чтобы по максимуму избежать загрузки файлов, которые у меня есть уже в кэше и которые не менялись на серваке в инете.
Добавлено: 28 Мая 2011, 17:47:15

бла-бла-бла

- ReadTimeOut (500)

бла-бла-бла
Опаньки!

Это то, о чём я думаю и о чём мечтал ТУТСмущен Да? yahoo
Я имею ввиду пункт 4.

Добавлено: 28 Мая 2011, 18:07:07

Задержка появления хинта в мониторе
TreeHintDelay (200)
А это "что за зверь такой"(с)? Шокирован
Это типа время, спустя которое, URL из нижней половине монитора отображается и в верхней? Смущен
Сообщить модератору   Записан
Доктор ТуамОсес
Гость
« Ответ #45 : 20 июля 2011, 17:01:13 »

Ну так что?
Ответов не будет?  :Улыбка
Или мне, как в известной пословице подождать 3 года? Не могу понять
Сообщить модератору   Записан
Доктор ТуамОсес
Гость
« Ответ #46 : 01 сентября 2011, 23:22:21 »

Все "твики" добавляются в секцию [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 Offline

Сообщений: 6383


« Ответ #47 : 02 сентября 2011, 11:14:21 »

Доктор ТуамОсес
Все, что можно было Вам уже сообщили. Читайте документацию и форум. Развлекать Вас разговорами я не имею возможности.
Сообщить модератору   Записан
Доктор ТуамОсес
Гость
« Ответ #48 : 02 сентября 2011, 13:26:56 »

Причём тут "развлекать разговорами"!?  Шокирован
Просто если уж ты реализовываешь какие-то фичи, то будь любезен описывать их В HELP-е.
А то у тебя прога имеют версии от 2011 года, а HELP датирован аж 2006-м годом  Читай доки!

А то получается фичи-то ты сделал, а для чего они нужны? Как их использовать? Как они связаны с ранее реализованными? Не понятно. А  телепаты все в отпуске.

Тогда нафига их делать если юзверь всё равно не сможет их заюзать, потому что не знает для чего они нужны и на что влияют.
Добавлено: 02 Сентября 2011, 13:19:42

Или ты как любой прогер не любишь писать доки на свои проги?
Я тебя понимаю: сам люблю больше проги писать, чем доки на них.

Просто, понимаешь, если нет нормальной документации на прогу, то её ценность сразу падает на порядки.

Ибо как смысл юзать "вещь в себе"?

Дай мне ссылку на полный хэлп к HC от 2011 года.

Или такого нет?
Сообщить модератору   Записан
stealzy
Пользователь
**

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

Сообщений: 52


« Ответ #49 : 01 февраля 2015, 03:55:41 »

Добавил в секцию TMainForm
SendExpiresHeaderField=True
StopDownloadingOldFiles=True
Изменений не заметил.
Неменяющийся html скачивается заново, на этом форуме, в частности.
If-Modified-Since, Останавливать загрузку старых файлов — галки стоят.
Сообщить модератору   Записан

HC 1.0.0.551
Страниц: 1 2 3 [Все]   Вверх
  Отправить эту тему    Печать  

 
Перейти в: