Главная
Форум
Контакты
Купить
Поддержи проект
Поиск
Искать:
Расширенный поиск
[Закрыть]
Правила форума
Войти
Регистрация
Russian
English
HandyCache форум
Главная категория
»
Новые предложения
»
Увеличение эффективности кэша клиента (I-M-S, I-N-M, Expires и т.п.)
Имя пользователя:
1 час
1 день
1 неделя
1 месяц
Навсегда
Пароль:
Страниц: [
1
]
2
3
Все
Вниз
« предыдущая тема
следующая тема »
Отправить эту тему
Печать
Автор
Тема: Увеличение эффективности кэша клиента (I-M-S, I-N-M, Expires и т.п.) (Прочитано 44366 раз)
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 пунктов: читал несколько раз, что-то наворочено всего много. Или сегодня плохо получается сосредоточиться.
Сообщить модератору
Записан
Страниц: [
1
]
2
3
Все
Вверх
Отправить эту тему
Печать
« предыдущая тема
следующая тема »
Перейти в:
Пожалуйста, выберите назначение:
-----------------------------
Главная категория
-----------------------------
=> Общие вопросы
=> Новые предложения
=> Дополнения, плагины
=> Сжатие трафика
=> English forum
=> Indonesian forum
-----------------------------
Гостевая
-----------------------------
=> Гостевая
-----------------------------
Дела домашние
-----------------------------
=> Сайт и форум HandyCache
=> Курилка
© 2006-2014 HandyCache Team. Все права защищены.
Загружается...