Страниц: 1 [2] 3  Все   Вниз
  Отправить эту тему    Печать  
Автор Тема: Увеличение эффективности кэша клиента (I-M-S, I-N-M, Expires и т.п.)  (Прочитано 44361 раз)
0 Пользователей и 1 Гость смотрят эту тему.
Михаил
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.
Сообщить модератору   Записан
Страниц: 1 [2] 3  Все   Вверх
  Отправить эту тему    Печать  

 
Перейти в: