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

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

Сообщений: 5194



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

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

Сообщений: 5194



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

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

Сообщений: 5194



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

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

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

Сообщений: 5194



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

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

Сообщений: 5194



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

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

Сообщений: 5194



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

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

Сообщений: 5194



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

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

Сообщений: 5194



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

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

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

Сообщений: 5194



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

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

Сообщений: 5194



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

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

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

Сообщений: 5194



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

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

Сообщений: 6186


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

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

 
Перейти в: