+  HandyCache форум
|-+  Главная категория» Новые предложения» Использование времени устаревания (expiration mechanism)
Имя пользователя:
Пароль:
Страниц: [1]   Вниз
« предыдущая тема следующая тема »
  Отправить эту тему    Печать  
Автор Тема: Использование времени устаревания (expiration mechanism)  (Прочитано 22627 раз)
0 Пользователей и 1 Гость смотрят эту тему.
DenZzz
Модератор
*****

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

Сообщений: 5589
« : 22 февраля 2007, 08:44:59 »
Цитата: Михаил от 09 февраля 2007, 21:41:22
Сейчас НС не может использовать заложенный в HTTP механизм времени устаревания (expiration). Сервер часто посылает в ответе в поле "Expires:" или "Cache-Control: max-age=" дату/время, до истечения которой файл точно изменяться не будет. До этого времени мы смело можем не обращаться к серверу невзирая на содержание списков "Только из кэша" и "Не обновлять", не проверять If-Modified-Since, а смело выдавать файл из кэша. Для этого нам надо сохранять указанное поле (max-age, а при его отсутствии Expires) в индексе.

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

Можно писать дату устаревания прямо в дату модификации сохраняемого в кэш файла!

Например, когда в заголовках ответа сервера есть информации об устаревании контента (Cache-Control: s-maxage=... , Cache-Control: max-age=... , Expires:... и т.п.), то мы меняем дату модификации файла на (system_time + s-maxage) или на (system_time + max-age) или на Expires...

С целью уменьшения нагрузки на файловую систему не изменять в кэше дату модификации файла (оставлять дату, присвоенную файловой системой):
1. Если в заголовках нет данных о времени устаревания контента или сервер не разрешает нам его кэшировать (max-age=0, no-cache и т.п.).
2. Если значение заголовка Expires < текущей системной даты.
3. Если (Expires - system_time), s-maxage или max-age не попадают в настраиваемый интервал. По умолчанию: min=10 минут, max=1 год.

Выгода:
В следующий раз, когда нам понадобится файл, HC как и сейчас проверит его дату в кэше, и если она окажется больше системной даты, то вместо проверки списка "Не обновлять", формирования заголовка "If-Modified-Since" и отправки запроса на сервер HC сразу отдаст файл из кэша "200 From cache (HC)" либо просто ответит браузеру "304 Not Modified (HC)"!
« Последнее редактирование: 22 февраля 2007, 12:07:31 от DenZzz » Сообщить модератору   Записан
Михаил
Gold beta tester
*****

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

Сообщений: 5513
« Ответ #1 : 22 февраля 2007, 12:24:33 »
DenZzz
А как отнесутся система/стороннее ПО к дате изменения, превышающей текущую и/или дату последнего доступа? Думаю, не очень хорошо.
« Последнее редактирование: 22 февраля 2007, 12:41:38 от Михаил » Сообщить модератору   Записан
DenZzz
Модератор
*****

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

Сообщений: 5589
« Ответ #2 : 22 февраля 2007, 12:42:57 »
Цитата: Михаил от 22 февраля 2007, 12:24:33
DenZzz
А как отнесутся система/стороннее ПО к дате изменения, превышающей текущую?

Системе абсолютно все равно! Можно менять дату файлов хоть на год вперед, хоть на 2 - проглотит без вопросов!

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

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

Сообщений: 5513
« Ответ #3 : 22 февраля 2007, 14:57:29 »
DenZzz
Цитировать
А как поведет себя стороннее ПО, зависит от степени его "кривизны"!
Остается осадок, что "кривизну"-то вносим как раз мы. Улыбка
Сделать так в принципе можно, согласен. Для начала хотя бы опционально, чтоб потестировать можно было да и отказаться при возникновении проблем. Только как в этом случае (при проблеме) даты взад исправить? Ведь программы бета-тестирования не существует...
А можно и потерпеть до индексов или чего там еще Подмигивающий
« Последнее редактирование: 22 февраля 2007, 15:01:30 от Михаил » Сообщить модератору   Записан
DenZzz
Модератор
*****

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

Сообщений: 5589
« Ответ #4 : 22 февраля 2007, 15:37:51 »
Цитата: Михаил от 22 февраля 2007, 14:57:29
Остается осадок, что "кривизну"-то вносим как раз мы. Улыбка
Сделать так в принципе можно, согласен. Для начала хотя бы опционально, чтоб потестировать можно было да и отказаться при возникновении проблем.

Можешь назвать софт, который будет работать с кэшем HC и не приемлет "будущие" даты?
Кроме старых Нортоновских утилит, которые так и норовят эти даты сделать текущими, я больше не встречал!

Цитировать
Только как в этом случае (при проблеме) даты взад исправить?

Легко! Тем же Total Commander-ом или FAR-ом! Но думаю, это не пригодится...

Цитировать
Ведь программы бета-тестирования не существует...

Собственно, сейчас все версии HC c буковкой "b", т.е. беты, а все пользователи - "бета-тестеры"! Улыбка
Вот выйдет версия 1.0 - назовем ее "релизом"!

Цитировать
А можно и потерпеть до индексов или чего там еще Подмигивающий

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

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

Сообщений: 5513
« Ответ #5 : 22 февраля 2007, 17:31:39 »
DenZzz
Цитировать
Можешь назвать софт, который будет работать с кэшем HC и не приемлет "будущие" даты?
Нет. Но остаются опасения, что это не гарантирует действительное отсутствие такого софта. А историк туда часом не лезет?
Цитировать
мы меняем дату модификации файла на (system_time + s-maxage) или на (system_time + max-age) или на Expires...
Вместо system_time предлагаю брать содержимое поля Date: заголовка ответа.
« Последнее редактирование: 22 февраля 2007, 17:40:22 от Михаил » Сообщить модератору   Записан
Михаил
Gold beta tester
*****

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

Сообщений: 5513
« Ответ #6 : 23 февраля 2007, 01:50:40 »
DenZzz
Цитировать
3. Если (Expires - system_time), s-maxage или max-age не попадают в настраиваемый интервал. По умолчанию: min=10 минут, max=1 год.
Не вижу смысла в параметре "max". Что он дает?
Сообщить модератору   Записан
DenZzz
Модератор
*****

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

Сообщений: 5589
« Ответ #7 : 23 февраля 2007, 12:20:12 »
Цитата: Михаил от 22 февраля 2007, 17:31:39
А историк туда часом не лезет?

Во время текущей работы - нет. Он берет даты из файлов очереди последних посещённых ссылок, формируемой HC.
А вот при первом наполнении истории по файлам кэша - я не в курсе, какую дату он использует. Но думаю, если он смотрит дату модификации и она оказалась больше системной, то он может брать дату создания или дату доступа.

Цитировать
Вместо system_time предлагаю брать содержимое поля Date: заголовка ответа.

Считаю, что время прохождения запроса от его отправки до приема составляет максимум несколько секунд, поэтому им можно принебречь! Мы уже обсуждали это в теме: "Сохранять или нет даты, переданные с сервера?"

Цитировать
Не вижу смысла в параметре "max". Что он дает?

Мне попадались на глаза сервера, где был 2030 год в Expires! Думаю, хранить такие даты бессмысленно - вряд ли файл долежит в кэше до 2030 года...

Поэтому предлагаю параметр max обрабатывать так:
если (Expires - system_time), s-maxage или max-age > max , то в кэш пишем дату (system_time + max) .
Сообщить модератору   Записан
Михаил
Gold beta tester
*****

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

Сообщений: 5513
« Ответ #8 : 23 февраля 2007, 13:50:51 »
DenZzz
Цитировать
Считаю, что время прохождения запроса от его отправки до приема составляет максимум несколько секунд, поэтому им можно принебречь! Мы уже обсуждали это в теме: "Сохранять или нет даты, переданные с сервера?"
Там предложение пренебречь еще как-то можно было понять, т.к. Date: хранить негде было. Зачем пренебрегать теперь, если можно и правильно этого не делать? Date: у нас есть, max-age и s-maxage указываются относительно него. Какие проблемы?
Цитировать
Мне попадались на глаза сервера, где был 2030 год в Expires! Думаю, хранить такие даты бессмысленно - вряд ли файл долежит в кэше до 2030 года...
Мне тоже попадались такие. Ничем не хуже, чем "не обновлять никогда". Однако ж последнее мы с легкостью допускаем в списке "Н". Пусть остается 2030 г. Есть у пользователя сомнения - отключит "чтение из кэша", и URL проверится на обновление.
« Последнее редактирование: 23 февраля 2007, 13:55:47 от Михаил » Сообщить модератору   Записан
DenZzz
Модератор
*****

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

Сообщений: 5589
« Ответ #9 : 23 февраля 2007, 19:22:31 »
Цитата: Михаил от 23 февраля 2007, 13:50:51
Date: у нас есть, max-age и s-maxage указываются относительно него. Какие проблемы?

Если бы время на сервере и клиенте было строго синхронизировано с GMT, то и в этом случае разница в несколько секунд никому не важна - только лишние траты ресурсов на анализ заголовка Date!
А когда время рассинхронизировано, то (system_time + max-age) будет даже точнее!

Цитировать
Мне тоже попадались такие. Ничем не хуже, чем "не обновлять никогда". Однако ж последнее мы с легкостью допускаем в списке "Н". Пусть остается 2030 г.

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

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

Сообщений: 5513
« Ответ #10 : 23 февраля 2007, 21:58:18 »
DenZzz
Цитировать
разница в несколько секунд никому не важна
"Несколько секунд" бывает не всегда. Возьми, например, http://www.nnm.ru/favicon.ico. Там набегает 11 часов.
Цитировать
Если бы была хоть малейшая уверенность, что файл действительно пролежит в кэше или на сервере до указанного времени и понадобится вновь в 2030 году, то был бы смысл сохранять такую большую дату...
Непонятно, чем эта уверенность, исходящая от автора сайта, хуже нашей уверенности в том, что URL никогда (хоть до 3000 г.) не обновится?
Цитировать
А вот при первом наполнении истории по файлам кэша - я не в курсе, какую дату он использует. Но думаю, если он смотрит дату модификации и она оказалась больше системной, то он может брать дату создания или дату доступа.
Можешь спросить у автора?
« Последнее редактирование: 23 февраля 2007, 22:07:49 от Михаил » Сообщить модератору   Записан
DenZzz
Модератор
*****

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

Сообщений: 5589
« Ответ #11 : 23 февраля 2007, 22:43:10 »
Цитата: Михаил от 23 февраля 2007, 21:58:18
"Несколько секунд" бывает не всегда. Возьми, например, http://www.nnm.ru/favicon.ico. Там набегает 11 часов.

У меня на GPRS выходит максимум 10 секунд и это с учетом запроса на DNS-сервер:

Цитировать
23.02.2007 23:10:25 # 877: DNS resolve www.nnm.ru --> 89.111.180.41
 
23.02.2007 23:10:32 # 877 >>> URL: http://www.nnm.ru/favicon.ico
Connected to host: 89.111.180.41, port: 80
23.02.2007 23:10:32 # 877 >>> URL: http://www.nnm.ru/favicon.ico
GET /favicon.ico HTTP/1.1
...

23.02.2007 23:10:35 # 877 <<< URL: http://www.nnm.ru/favicon.ico
HTTP/1.1 200 OK


Цитировать
Непонятно, чем эта уверенность, исходящая от автора сайта, хуже нашей уверенности в том, что URL никогда (хоть до 3000 г.) не обновится?

Сомневаюсь, что эта уверенность у него есть! Думаю, он просто шутит...

Цитировать
Можешь спросить у автора?

rs в последнее время редко бывает на форуме. Может, кто из пользователей Историка подскажет...
« Последнее редактирование: 23 февраля 2007, 22:55:36 от DenZzz » Сообщить модератору   Записан
Михаил
Gold beta tester
*****

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

Сообщений: 5513
« Ответ #12 : 23 февраля 2007, 22:54:59 »
DenZzz
Цитировать
У меня на GPRS выходит максимум 10 секунд и это с учетом запроса на DNS-сервер
Не, я не про это.
Запрос: (послан сегодня в 18.10 GMT, т.е. это system_time):
GET /favicon.ico HTTP/1.0
User-Agent: Opera/9.20 (Windows NT 5.1; U; ru)
Host: www.nnm.ru
Accept: text/html, application/xml;q=0.9, application/xhtml+xml, image/png, image/jpeg, image/gif, image/x-xbitmap, */*;q=0.1
Accept-Language: ru,ru-RU;q=0.9,en;q=0.8
Accept-Charset: iso-8859-1, utf-8, utf-16, *;q=0.1
Accept-Encoding: gzip, deflate
Referer: http://www.nnm.ru/
Proxy-Connection: close
Ответ:
HTTP/1.1 200 OK
Server: nginx/0.3.33
Date: Fri, 23 Feb 2007 07:23:55 GMT
Content-Type: image/x-icon
Content-Length: 197
Last-Modified: Sun, 10 Dec 2006 14:06:15 GMT
Expires: Fri, 02 Mar 2007 07:23:55 GMT
Cache-Control: max-age=604800
Accept-Ranges: bytes
Proxy-Connection: Close

Т.о., Date: < system_time ~ на 11 часов.
Сообщить модератору   Записан
Сергей
Beta tester
*****

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

Сообщений: 621
« Ответ #13 : 23 февраля 2007, 23:32:09 »
Цитата: Михаил от 23 февраля 2007, 22:54:59
Т.о., Date: < system_time ~ на 11 часов.

У меня время совпадает. Как ты этого добился?
Сообщить модератору   Записан
DenZzz
Модератор
*****

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

Сообщений: 5589
« Ответ #14 : 23 февраля 2007, 23:33:57 »
Михаил

Цитировать
Запрос: (послан сегодня в 18.10 GMT, т.е. это system_time)

Ты где живешь? На Гринвиче? Подмигивающий
У меня местное время = system_time = GMT+4 = MSK+1

Цитировать
Т.о., Date: < system_time ~ на 11 часов.

Не, у меня время в Date было правильное!


Гораздо больше распространен вариант - когда на сервере время правильное, а у пользователя сбито! Тогда логичнее считать время устаревания, как (system_time + max-age).
« Последнее редактирование: 23 февраля 2007, 23:39:33 от DenZzz » Сообщить модератору   Записан
Михаил
Gold beta tester
*****

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

Сообщений: 5513
« Ответ #15 : 24 февраля 2007, 00:08:07 »
Сергей,
DenZzz
Только что послал опять - опять то же самое.
Давайте разберемся, тем более что это далеко не единичный, а частый расклад.
Как ответил сервер у вас при запросе этого URL?
Цитировать
Ты где живешь? На Гринвиче?
У меня местное время = system_time = GMT+4 = MSK+1
Специально привел свой system_time в GMT, чтоб показать разницу с Date:.
Цитировать
Не, у меня время в Date было правильное!
Оно и так, и так может быть правильное. Как мне помнится, Date - это не текущее время сервера или вышестоящего прокси в момент начала коннекта с нами, а время, когда он сформировал тот ответ, который направляет нам. Сформировать его он мог гораздо раньше (в данном случае на 11 часов) в ответ на запросы других пользователей. И не менять его, зная, что ни одно поле пока не подлежит изменению.
« Последнее редактирование: 24 февраля 2007, 00:24:40 от Михаил » Сообщить модератору   Записан
DenZzz
Модератор
*****

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

Сообщений: 5589
« Ответ #16 : 24 февраля 2007, 10:56:04 »
Цитата: Михаил от 24 февраля 2007, 00:08:07
Давайте разберемся, тем более что это далеко не единичный, а частый расклад.
Как ответил сервер у вас при запросе этого URL?

Так же, как и вчера, у меня время в Date правильное:

Цитировать
24.02.2007 11:35:22 # 106 <<< URL: http://www.nnm.ru/favicon.ico
HTTP/1.1 200 OK
Server: nginx/0.3.33
Date: Sat, 24 Feb 2007 07:35:19 GMT
Content-Type: image/x-icon
Content-Length: 197
Last-Modified: Sun, 10 Dec 2006 14:06:15 GMT
Connection: close
Expires: Sat, 03 Mar 2007 07:35:19 GMT
Cache-Control: max-age=604800
Accept-Ranges: bytes
Сообщить модератору   Записан
Михаил
Gold beta tester
*****

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

Сообщений: 5513
« Ответ #17 : 24 февраля 2007, 17:10:03 »
DenZzz
Посмотри:
http://www.nnm.ru/img/default/bg/winter/7.jpg
http://www.nnm.ru/img/default/logo/winter/7.gif
http://www.nnm.ru/img/default/razdel/topmenu/newz.gif
И еще много с этого сайта.
http://www.gks.ru/wps/menu/menu_service.js
и куча URL с этого сайта.
http://www.allbest.ru/i/gray.gif
http://www.allbest.ru/i/corner.jpg
И куча URL с этого сайта.
Я взял 4 произвольных сайта методом тыка. И из них в 3 - такое есть.
Да далеко и ходить не нужно: взял http://handycache.ru/forum/Themes/SlickPro_Graphite/images/staradmin.gif - там и еще в куче фалов каталога .../images/ тоже Date из далекого прошлого указывается.
Частое несоответствие значения поля Date текущему времени - это факт.
« Последнее редактирование: 24 февраля 2007, 17:48:29 от Михаил » Сообщить модератору   Записан
DenZzz
Модератор
*****

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

Сообщений: 5589
« Ответ #18 : 24 февраля 2007, 20:44:12 »
Михаил

Пробежался почти по всем твоим ссылками - везде время в Date правильное! Разница с моим системным всего несколько секунд! Только на http://www.gks.ru/ их Date спешит yна 5 минут...

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

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

Сообщений: 5513
« Ответ #19 : 24 февраля 2007, 21:20:36 »
DenZzz
Реально - это провайдер. Присмотрелся - такое происходит со всеми рисунками и явой. За свой софт "зуб даю" Подмигивающий - не делает такого.
Но как бы то ни было, мне придется отталкиваться от поля Date, иначе max-age будет работать неправильно.
Сообщить модератору   Записан
Страниц: [1]   Вверх
  Отправить эту тему    Печать  

« предыдущая тема следующая тема »
 
Перейти в:  



Powered by SMF 1.1.3 SMF © 2006, Simple Machines LLC
Joomla Bridge by JoomlaHacks.com