Главная
Форум
Контакты
Купить
Поддержи проект
Поиск
Искать:
Расширенный поиск
[Закрыть]
Правила форума
Войти
Регистрация
Russian
English
HandyCache форум
Главная категория
»
Новые предложения
»
Увеличение эффективности кэша клиента (I-M-S, I-N-M, Expires и т.п.)
Имя пользователя:
1 час
1 день
1 неделя
1 месяц
Навсегда
Пароль:
Страниц:
1
[
2
]
3
Все
Вниз
« предыдущая тема
следующая тема »
Отправить эту тему
Печать
Автор
Тема: Увеличение эффективности кэша клиента (I-M-S, I-N-M, Expires и т.п.) (Прочитано 44400 раз)
0 Пользователей и 1 Гость смотрят эту тему.
Михаил
Gold beta tester
Репутация: +337/-14
Offline
Сообщений: 5513
Re: Увеличение эффективности If-Modified-Since
«
Ответ #20 :
16 мая 2008, 21:13:13 »
Цитата: mai62 от 16 мая 2008, 20:38:50
Про алгоритм из 5 пунктов: читал несколько раз, что-то наворочено всего много.
Общая мысль - эффективнее использовать собственный кэш клиента. Если клиент шлет в запросе IMS, то сейчас НС это плохо использует - ищет файл в своем кэше и проверяет список Н сообразно дате этого файла. А можно в кэш не лезть, а проверять список "Н" по дате, указанной в IMS клиента.
Т.е. решение "Не обновлять" принимаем в отношении файла из кэша клиента, а не из кэша НС. Экономим на отсутствии обращений к файловой системе (поиск файла в кэше НС становится в подавляющем большинстве таких случаев ненужен). Если даже кэш на винчестере - это выигрыш, а когда на сетевом диске - БОЛЬШОЙ выигрыш.
Попутно устраняется баг с возможной выдачей пользователю неактуального контента.
«
Последнее редактирование: 16 мая 2008, 21:42:01 от Михаил
»
Сообщить модератору
Записан
Михаил
Gold beta tester
Репутация: +337/-14
Offline
Сообщений: 5513
Re: Увеличение эффективности If-Modified-Since
«
Ответ #21 :
12 июня 2008, 11:38:49 »
Теперь такой пример. НС использует два каталога кэша - локальный и сетевой (только для чтения).
1. Файл подпадает под список Н (правило с критерием свежести) и содержится в обоих кэшах. В локальном каталоге он устарел по критерию свежести, а на сетевом лежит свежий. Запрашиваем файл... И НС тянет его из интернет несмотря на наличие в кэше!
2. Файл лежит в обоих кэшах. В локальном устарел, а в сетевом свеж относительно файла на сервере. Запрашиваем... И взамен ответа сервера 304 и взятия из кэша снова тянется из инета весь файл!
Что делать с этим?
Итого по этой теме уже много накопилось мыслей. Помимо данного поста, это
http://handycache.ru/forum/index.php?topic=782.msg8401#msg8401
http://handycache.ru/forum/index.php?topic=782.msg8413#msg8413
http://handycache.ru/forum/index.php?topic=782.msg11857#msg11857
Сообщить модератору
Записан
mai62
Автор HC
Репутация: +226/-4
Offline
Сообщений: 6383
Re: Увеличение эффективности If-Modified-Since
«
Ответ #22 :
12 июня 2008, 11:48:26 »
Михаил
Я не считаю твои предложения в этой теме неправильными или ненужными. Причина задержки в том, что они требуют нетривиальных изменений (а может мне это только кажется с первого взгляда) и я пока не нашел времени этим заняться.
Спасибо за настойчивость.
Сообщить модератору
Записан
DenZzz
Модератор
Репутация: +179/-11
Offline
Сообщений: 5589
Re: Увеличение эффективности If-Modified-Since
«
Ответ #23 :
13 июня 2008, 15:01:16 »
Цитата: Михаил от 12 июня 2008, 11:38:49
Что делать с этим?
ИМХО, лучше второй раз скачать из инета, чем удваивать количество обращений к диску! Выяснение дат файлов на тормозном сетевом диске отнимет много времени, причем это время часто будет потрачено впустую...
Сообщить модератору
Записан
Михаил
Gold beta tester
Репутация: +337/-14
Offline
Сообщений: 5513
Re: Увеличение эффективности If-Modified-Since
«
Ответ #24 :
13 июня 2008, 16:14:33 »
В случае, описанном в п.1, однозначно нужно проверять второй кэш.
Цитировать
это время часто будет потрачено впустую
Это может иметь место только при ситуации из п.2. Часто или нет, зависит от конкретного наполнения кэшей, разницы в частоте записи в каждый из кэшей, тарифа интернет (повременка, помегабайтный), наличия ограничения объема интернет-трафика для пользователя, от того, какая скорость доступа ко второму кэшу (локальный, сетевой, флэш и др.). Имхо, правильно предоставить выбор пользователю, как поступать в этом случае.
Сообщить модератору
Записан
DenZzz
Модератор
Репутация: +179/-11
Offline
Сообщений: 5589
Re: Увеличение эффективности If-Modified-Since
«
Ответ #25 :
13 июня 2008, 16:25:46 »
Цитата: Михаил от 13 июня 2008, 16:14:33
Цитировать
это время часто будет потрачено впустую
Это может иметь место только при ситуации из п.2.
И в случае из п.1, когда файл в сетевом кэше также окажется просроченным - время на выяснение даты потратим, а качать придется из инета.
Сообщить модератору
Записан
Михаил
Gold beta tester
Репутация: +337/-14
Offline
Сообщений: 5513
Re: Увеличение эффективности If-Modified-Since
«
Ответ #26 :
13 июня 2008, 16:36:56 »
Цитата: DenZzz от 13 июня 2008, 16:25:46
И в случае из п.1, когда файл в сетевом кэше также окажется просроченным - время на выяснение даты потратим, а качать придется из инета.
Думаю, что необходимость этого уже охватывается нашим умыслом, когда мы назначаем второй кэш. Всякий файл, за которым по итогам анализа первого кэша уже однозначно надо лезть в интернет, проверяется на наличие во втором кэше. Так сказать, последний рубеж обороны.
Сообщить модератору
Записан
mai62
Автор HC
Репутация: +226/-4
Offline
Сообщений: 6383
Re: Увеличение эффективности If-Modified-Since
«
Ответ #27 :
22 июня 2008, 13:42:33 »
Просьба конструктивно обсудить эту проблему и дать согласованный алгоритм, чтобы я мог быстро это сделать.
Сообщить модератору
Записан
Дем
Постоялец
Репутация: +6/-3
Offline
Сообщений: 167
Re: Увеличение эффективности If-Modified-Since
«
Ответ #28 :
03 июля 2008, 13:25:10 »
алгоритм - проверяем файлы, используем более новый.
тут ещё один вопрос - может кому будет нужно обновить файл во втором кеше из первого.
А вообще, такие узкоцелевые вопросы проще поручить решать самому пользователю через скрипты
Сообщить модератору
Записан
Михаил
Gold beta tester
Репутация: +337/-14
Offline
Сообщений: 5513
Сообщать кэшу клиента о времени устаревания
«
Ответ #29 :
15 июля 2008, 01:01:33 »
Для повышения эффективности собственного кэша клиента в паре с НС предлагаю при срабатывании списка Не обновлять передавать клиенту заголовок Expires с датой устаревания файла по критерию свежести списка Н (1 год, если критерия нет).
Теперь клиент пришлет повторный запрос к НС только по истечении критерия свежести и не будет тратить время на промежуточные проверочные запросы к НС.
Такое поведение сделать опциональным.
Скриптом реализовывать не очень желательно.
Сообщить модератору
Записан
Дем
Постоялец
Репутация: +6/-3
Offline
Сообщений: 167
Re: Сообщать кэшу клиента о времени устаревания
«
Ответ #30 :
17 июля 2008, 11:19:05 »
Мало поможет. Потому как файл для отображения всё равно надо откуда-то взять, а кеш браузера большинство пользователей НС урезает до минимума.
Сообщить модератору
Записан
Михаил
Gold beta tester
Репутация: +337/-14
Offline
Сообщений: 5513
Re: Сообщать кэшу клиента о времени устарева&
«
Ответ #31 :
17 июля 2008, 15:02:27 »
Это существенно поможет тем, кто не урезает кэш клиента. Я не урезаю, т.к. скорость работы в интернете ценю больше экономии места на диске. Собственно, для повышения этой скорости ценой расходования дискового пространтсва и создан НС. Читал, есть и другие, поступающие так же. Диск у меня настолько огромен по отношению к планам его наполнения каким-либо софтом, медиа и пр., что вопрос об экономии 500 МБ под кэш браузера не встанет даже в отдаленной перспективе. А собственное время хочется экономить максимально.
По сути, реализовав это предложение мы можем заставить кэш браузера работать в соответствии с правилами НАШЕГО списка "Не обновлять". Средствами самого браузера это сделать невозможно.
«
Последнее редактирование: 17 июля 2008, 15:27:01 от Михаил
»
Сообщить модератору
Записан
Сергей
Beta tester
Репутация: +9/-2
Offline
Сообщений: 621
Re: Сообщать кэшу клиента о времени устаревания
«
Ответ #32 :
17 июля 2008, 21:08:58 »
Поддерживаю. Нет никакого смысла урезать кэш браузера. А вот помочь HC более эффективно взаимодействовать с браузером стоит.
Сообщить модератору
Записан
Михаил
Gold beta tester
Репутация: +337/-14
Offline
Сообщений: 5513
Re: Увеличение эффективности If-Modified-Since
«
Ответ #33 :
07 августа 2008, 10:24:20 »
Цитата: mai62 от 22 июня 2008, 13:42:33
Просьба конструктивно обсудить эту проблему и дать согласованный алгоритм, чтобы я мог быстро это сделать.
Вот все предложения по улучшению эффективности взаимодействия с кэшем клиента:
1. Если (Last-Modified ответа 200 сервера <= If-Modified-Since запроса НС к серверу), то:
- незамедлительно рвем соединение с сервером, отказываясь от получения ответа
- если IMS был от клиента, то возвращаем 304, если его вставлял НС, возвращаем файл из кэша.
2. Если пришел запрос с IMS, то:
- при проходе списка Н проверяем на соответствие критерию свежести не дату файла в кэше как сейчас, а этот IMS. Если соответствует, прерываем проверку списка Н и возвращаем 304
- если список Н не сработал, только тогда проверяем наличие файла в кэше и соответствие критериям свежести списка Н даты этого файла (для этого второй проход по списку Н не нужен). Если сработало, то отдаем файл из кэша как сейчас
- если по результатам двух предыдущих шагов список Н так и не сработал, хотя регэксп соответствовал (т.е. Н не сработал только из-за критерия свежести), то подменить в ответе сервера (даже если это 304) значение поля Last-Modified на Сейчас или добавить такое поле, если его нет
- если (сервер ответил 304) и (IMS клиента >= ДатыФайлаВКэше), то обновляем дату файла в кэше.
3. Если пришел запрос с If-None-Match, а сервер ответил 304, то всегда отдаем это 304 клиенту. В кэш за файлом не лезем.
4. Если пришел ответ 200 без Last-Modified и ETag, то в ответ добавляем LM=Сейчас.
Сообщить модератору
Записан
Михаил
Gold beta tester
Репутация: +337/-14
Offline
Сообщений: 5513
Re: Увеличение эффективности If-Modified-Since
«
Ответ #34 :
07 августа 2008, 14:03:30 »
Еще вот забыл:
5. При срабатывании списка Н передавать клиенту заголовок Expires с датой устаревания файла по критерию свежести списка Н (1 год, если критерия нет).
Такое поведение сделать опциональным.
Сообщить модератору
Записан
DenZzz
Модератор
Репутация: +179/-11
Offline
Сообщений: 5589
Re: Увеличение эффективности If-Modified-Since
«
Ответ #35 :
07 августа 2008, 16:14:50 »
Цитата: Михаил от 07 августа 2008, 10:24:20
- если список Н не сработал,
только тогда проверяем наличие файла в кэше
и соответствие критериям свежести списка Н даты этого файла (для этого второй проход по списку Н не нужен). Если сработало, то отдаем файл из кэша как сейчас
Эти данные у HC уже есть до проверки списка Н - они нужны для работы скриптов по заголовкам запросов. Надеюсь, HC их запоминает и второй раз за ними в кэш не лезет...
Цитировать
- если (сервер ответил 304) и (IMS клиента
>
= ДатыФайлаВКэше), то обновляем дату файла в кэше.
Тут ты знаком не ошибся?
Цитировать
4. Если пришел ответ 200 без Last-Modified и ETag, то в ответ добавляем LM=Сейчас.
При существенной рассинхронизации системного времени сервера HC с сервером в инете в сочетании с работой п.1 получим постоянное чтение файлов из кэша, т.е. фактически неотключаемый автономный режим. Поэтому надо включение п.1 делать опциональным.
Вот твой алгоритм с моими поправками:
1. Если (Last-Modified ответа 200 сервера <= If-Modified-Since запроса НС к серверу)
, то:
- незамедлительно рвем соединение с сервером, отказываясь от получения ответа
- если IMS был от клиента, то возвращаем 304, если его вставлял НС, возвращаем файл из кэша и обновляем его дату.
Такое поведение сделать опциональным (в INI).
2. Если от клиента пришел запрос с IMS, то:
- при проходе списка Н если RegExp сработал, проверяем на соответствие критерию свежести IMS клиента. Если соответствует, возвращаем 304.
- если IMS клиента просрочен, проверяем по критерию свежести дату файла в кэше. Если соответствует, то отдаем файл из кэша.
- если по результатам двух предыдущих шагов ответ клиенту не сформирован, то делаем запрос на сервер с IMS клиента и подменяем в ответе сервера (даже если это 304) значение поля Last-Modified на "Сейчас" или добавляем такое поле, если его нет
- если (сервер ответил 304) и (IMS клиента <= ДатыФайлаВКэше), то обновляем дату файла в кэше.
2а. Если от клиента пришел запрос без IMS и If-None-Match, то:
- проверяем по критерию свежести дату файла в кэше. Если соответствует, то отдаем файл из кэша
- иначе, вставляем свой IMS и делаем запрос на сервер
- если сервер ответил 304, то обновляем дату файла в кэше и передаем его клиенту, как и сейчас.
3. Если пришел запрос с If-None-Match
, то свой IMS не вставляем (по RFC 2616 его все равно сервер проигнорирует!). Если сервер ответил 304, то всегда отдаем это 304 клиенту. В кэш за файлом не лезем, дату не обновляем.
4. Если пришел ответ 200 без Last-Modified и ETag
, то в ответ добавляем LM=Сейчас.
5. При срабатывании списка Н
передаем клиенту заголовок Expires с датой устаревания файла по критерию свежести, если он положителен (1 год, если критерия нет или он отрицателен).
Такое поведение сделать опциональным (в INI).
Сообщить модератору
Записан
Михаил
Gold beta tester
Репутация: +337/-14
Offline
Сообщений: 5513
Re: Увеличение эффективности If-Modified-Since
«
Ответ #36 :
07 августа 2008, 18:35:31 »
Цитата: DenZzz от 07 августа 2008, 16:14:50
Эти данные у HC уже есть до проверки списка Н - они нужны для работы скриптов по заголовкам запросов. Надеюсь, HC их запоминает и второй раз за ними в кэш не лезет...
Скрипты запросов могут быть отключены/не быть прописаны. Есть у НС эти данные при таком расладе?
Цитировать
Тут ты знаком не ошибся?
Согласен.
Цитировать
При существенной рассинхронизации системного времени сервера HC с сервером в инете в сочетании с работой п.1 получим постоянное чтение файлов из кэша, т.е. фактически неотключаемый автономный режим. Поэтому надо включение п.1 делать опциональным.
Согласен.
Цитировать
2. Если от клиента пришел запрос с IMS, то:
- при проходе списка Н если RegExp сработал, проверяем на соответствие критерию свежести IMS клиента. Если соответствует, возвращаем 304.
- если IMS клиента просрочен, проверяем по критерию свежести дату файла в кэше. Если соответствует, то отдаем файл из кэша.
Если регэксп сработал, а IMS не соответствует критерию свежести, то не надо сразу проверять дату файла. Ведь могут сработать следующие правила. Надо полностью пройти
весь
список Н с IMS и только после того как все строки Н не сработали, но регэксп срабатывал, сделать одну проверку на соответствие даты файла в кэше. По ее результатам принять решение о выдаче файла из кэша.
Сообщить модератору
Записан
DenZzz
Модератор
Репутация: +179/-11
Offline
Сообщений: 5589
Re: Увеличение эффективности If-Modified-Since
«
Ответ #37 :
07 августа 2008, 19:13:51 »
Цитата: Михаил от 07 августа 2008, 18:35:31
Скрипты запросов могут быть отключены/не быть прописаны. Есть у НС эти данные при таком расладе?
Учитывая, сколько новых вкусностей несут в себе скрипты в плане экономии трафика/времени, управления пользователями, ограничением скорости и трафика и т.д., думаю скрипты будут включены у многих...
В какой момент HC собирает сейчас информацию о файлах в кэше при выключенных скриптах, я точно не знаю.
Цитата: Михаил от 07 августа 2008, 18:35:31
сделать одну проверку на соответствие даты файла в кэше. По ее результатам принять решение о выдаче файла из кэша.
Как минимум 2 проверки: отдельно для положительных и отрицательных критериев свежести. Чтобы повторный прогон по всему списку не делать, нужно запоминать максимальные значения критериев свежести у сработавших RegExp: отдельно для положительных и отрицательных.
Сообщить модератору
Записан
Михаил
Gold beta tester
Репутация: +337/-14
Offline
Сообщений: 5513
Re: Увеличение эффективности кэша клиента (I-M-S, I
«
Ответ #38 :
22 ноября 2008, 09:22:13 »
п.4 лучше сделать так: Если пришел ответ 200 без Last-Modified и ETag, то в ответ добавляем LM=поле Date ответа. Тогда рассинхронизации по времени нет. Если Date нет (это бывает редко), то LM=Сейчас.
Не забыть надо и про
это
.
Сообщить модератору
Записан
mai62
Автор HC
Репутация: +226/-4
Offline
Сообщений: 6383
Re: Увеличение эффективности кэша клиента (I-M-S, I-N-M, Expires и т.п.)
«
Ответ #39 :
13 июля 2009, 00:43:20 »
Цитировать
1. Если (Last-Modified ответа 200 сервера <= If-Modified-Since запроса НС к серверу), то:
- незамедлительно рвем соединение с сервером, отказываясь от получения ответа
- если IMS был от клиента, то возвращаем 304, если его вставлял НС, возвращаем файл из кэша.
Разве сервер может ответить 200, если (Last-Modified ответа 200 сервера <= If-Modified-Since запроса НС к серверу)?
Он ведь ответит 304.
Сообщить модератору
Записан
Страниц:
1
[
2
]
3
Все
Вверх
Отправить эту тему
Печать
« предыдущая тема
следующая тема »
Перейти в:
Пожалуйста, выберите назначение:
-----------------------------
Главная категория
-----------------------------
=> Общие вопросы
=> Новые предложения
=> Дополнения, плагины
=> Сжатие трафика
=> English forum
=> Indonesian forum
-----------------------------
Гостевая
-----------------------------
=> Гостевая
-----------------------------
Дела домашние
-----------------------------
=> Сайт и форум HandyCache
=> Курилка
© 2006-2014 HandyCache Team. Все права защищены.
Загружается...