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

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

Сообщений: 5511



« : 14 января 2007, 16:42:19 »

Список условных прокси проверяется до всех остальных (по крайней мере до черного, белый и переадресацию проверять было лень). А по логике должен бы проверяться лишь после принятия окончательного решения о загрузке из Интернет (т.е. по блок-схеме сразу после ухода на ветку "нет" условия "Файл в Интернете большой?"). В результате исключим лишние проверки этого списка в случаях, когда в Интернет не лезем. Соответственно при этом уйдет ненужная информация о срабатывании этого списка из монитора.

Просьба обсудить. Если все так и есть - то в ToDo.
Сообщить модератору   Записан
Дем
Постоялец
***

Репутация: +6/-3
Offline Offline

Сообщений: 167



« Ответ #1 : 14 января 2007, 18:01:12 »

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

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

Сообщений: 5511



« Ответ #2 : 14 января 2007, 18:28:01 »

Согласен, надо до проверки условия "Файл в Интернете большой?"
« Последнее редактирование: 14 января 2007, 18:34:04 от Михаил » Сообщить модератору   Записан
DenZzz
Модератор
*****

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

Сообщений: 5589



« Ответ #3 : 14 января 2007, 21:15:56 »

Михаил

Цитировать
В результате исключим лишние проверки этого списка в случаях, когда в Интернет не лезем. Соответственно при этом уйдет ненужная информация о срабатывании этого списка из монитора.

А чем мешает эта информация? Думаешь, это ускорит работу? Сомневаюсь...

Кстати, сейчас попытал список "Условных прокси" при загрузке одного и того же блокируемого URL - информация, что УП сработал появляется в Мониторе только при первой блокировке, а потом уже нет!
Сообщить модератору   Записан
Михаил
Gold beta tester
*****

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

Сообщений: 5511



« Ответ #4 : 15 января 2007, 09:18:25 »

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

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

Сообщений: 5511



« Ответ #5 : 16 января 2007, 18:16:40 »

В FAQ имеется достаточно наглядная блок-схема работы НС.
Посмотрев ее, предлагаю обсудить пару оптимизаций.

1. После загрузки из Интернета грузить объект в браузер не после проверки списка "Запись в кэш", а непосредственно перед этим. Результат - маленькое, но приятное ускорение дохождения данных до наших глаз + маленькое сокращение количества линий в схеме.

2. При отсутствии URL в списке "Только из кэша" мы сразу идем копаться в кэше. Однако если его нет и в "Не обновлять", то мы все равно его скачиваем из интернета. Так чего же мы зря теряли время и шерстили кэш? В связи с этим проверку наличия файла в кэше лучше делать ПОСЛЕ обработки списка "Не обновлять". Только для этого надо реализовать постпроверку критерия свежести.
В качестве плюса имеем избегание лишних обращений к кэшу. Минусом же является пропорциональное увеличение количества обработок списка "Не обновлять". Однако первое делается посредством обращения к диску и поиском в зачастую огромном кэше, второе - только в памяти и в несравненно меньших объемах.

Итоговый вид схемы привел во вложении. Я сознательно не рисовал проверку размера файла как не относящуюся к данной теме.
Давайте обсудим...


* Схема работы HandyCache нынешняя.jpg (60.38 Кб, 561x864 - просмотрено 45 раз.)
« Последнее редактирование: 16 января 2007, 18:19:50 от Михаил » Сообщить модератору   Записан
DenZzz
Модератор
*****

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

Сообщений: 5589



« Ответ #6 : 16 января 2007, 22:19:05 »

Михаил

Цитировать
1. После загрузки из Интернета грузить объект в браузер не после проверки списка "Запись в кэш", а непосредственно перед этим. Результат - маленькое, но приятное ускорение дохождения данных до наших глаз + маленькое сокращение количества линий в схеме.

Во-первых, так и происходит! HC начинает качать новый объект, получает заголовки с первой порцией файла, отдает ее браузеру и ОДНОВРЕМЕННО проверяет список "Запись в кэш", чтобы определить, надо ли ПАРАЛЛЕЛЬНО писать файл в кэш или нет. Ускорять здесь нечего!

Во-вторых, ты постоянно говоришь о каком-то мифическом ускорении от сокращения числа списков и правил, но вынужден тебя огорчить, заметного ускорения не получится, это уже было раз проверено и даже описано в ФАКе!

Цитировать
В качестве плюса имеем избегание лишних обращений к кэшу. Минусом же является пропорциональное увеличение количества обработок списка "Не обновлять". Однако первое делается посредством обращения к диску и поиском в зачастую огромном кэше, второе - только в памяти и в несравненно меньших объемах.

Проверка наличия файла в огромном кэше занимает не так много времени, как может показаться, т.к. HC точно знает, где искать! У него есть точный путь! Возможный выигрыш в скорости нивелируется двойной проверкой списка "Не обновлять"!

К тому же, у HC есть RAM-кэш, в который записываются файлы, раз прочитанные из дискового кэша в текущем сеансе, и повторного обращения к диску за этими файлами уже не происходит! Проверка наличия и свежести этих файлов при 2 и следующих обращениях производятся только в памяти!

Цитировать
Итоговый вид схемы привел во вложении.

Где ветка "НЕТ" из списка "Запись в кэш" и куда она ведет?
« Последнее редактирование: 16 января 2007, 22:25:00 от DenZzz » Сообщить модератору   Записан
Михаил
Gold beta tester
*****

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

Сообщений: 5511



« Ответ #7 : 16 января 2007, 22:34:00 »

Цитировать
Во-первых, так и происходит!
Значит, надо изменить неправильную схему в FAQ

Цитировать
Возможный выигрыш в скорости нивелируется двойной проверкой списка "Не обновлять"!
Ты веришь в то, что говоришь? Зачем же RAM-кэш создан, если
Цитировать
Проверка наличия файла в огромном кэше занимает не так много времени, как может показаться
Исключить такую проверку - это как раз одна из его функций, как я понимаю.

Цитировать
Где ветка "НЕТ" из списка "Запись в кэш" и куда она ведет?
Ветки "НЕТ" нет (неплохой каламбур), потому что если запись в кэш не нужна, то дальше ничего не происходит.
« Последнее редактирование: 16 января 2007, 22:54:22 от Михаил » Сообщить модератору   Записан
DenZzz
Модератор
*****

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

Сообщений: 5589



« Ответ #8 : 16 января 2007, 22:52:13 »

Михаил

Цитировать
Значит, надо изменить неправильную схему в FAQ

Это не схема неправильная, это ты ее неправильно понимаешь! Схема логически верна в плане итогового результата и не претендует на точный алгоритм работы кода программы!

Блок проверки размера файла тоже нарисован не там, где он на самом деле есть, но это сознательно сделано для наглядности и простоты понимания логики работы HC...

Цитировать
Зачем же RAM-кэш создан, если
Цитировать
Проверка наличия файла в огромном кэше занимает не так много времени, как может показаться

В первую очередь, чтобы ускорить ПОВТОРНОЕ ЧТЕНИЕ из кэша файлов и проверки их СВЕЖЕСТИ, а не просто для проверки их наличия...

Кстати, еще было предложение создавать индексы кэша, но остановились на RAM-кэше, возможно, пока...
Сообщить модератору   Записан
Михаил
Gold beta tester
*****

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

Сообщений: 5511



« Ответ #9 : 16 января 2007, 23:08:48 »

DenZzz
Схемы обычно понимаются так, как они нарисованы, а не так как они мыслятся в чьей-то голове, доступа к которой из форума у меня нет.

А теперь ответь по существу (в скобках - мои ответы):
1. Имеет ли место экономия в случае реализации п.2 из заголовка темы? (да, и существенная, поскольку часть файлов будет пущена в обход проверки их существования в кэше, которое реализуется в БОЛЬШИНСТВЕ случаев доступом к диску).
2. Если да, то какова сложность реализации? (близка к нулю).

Так в чем же тогда проблема?
Сообщить модератору   Записан
DenZzz
Модератор
*****

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

Сообщений: 5589



« Ответ #10 : 16 января 2007, 23:32:18 »

Михаил

Цитировать
1. Имеет ли место экономия в случае реализации п.2 из заголовка темы?

Какая-то экономия возможно и будет, НО двойная проверка списка "Не обновлять" дает обратный эффект! В итоге, экономия вряд ли будет заметна "на глаз"!

Цитировать
да, и существенная

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

Еще замечу, что список "Не обновлять" в последней версии проверяется не только при наличии файла в кэше! Это необходимо для правильного формирования ответа "304", когда это необходимо (см. здесь).

Цитировать
2. Если да, то какова сложность реализации?

Это вопрос к mai62, а не ко мне!
Сообщить модератору   Записан
Михаил
Gold beta tester
*****

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

Сообщений: 5511



« Ответ #11 : 17 января 2007, 00:25:43 »

Цитировать
Возможный выигрыш в скорости нивелируется двойной проверкой списка "Не обновлять"!
Опубликуй, пожалуйста, результаты замеров, полученные в ходе этого "неголословного" исследования.

Цитировать
Это утверждение голословно!
Да, практических проверок не было. Давай сделаем это хотя бы частично в уме. Во-первых, сразу оговоримся, что никакой "двойной проверки" списка "Не обновлять" нет и в помине. Проверка как была, так и есть одна. В чем же получается разница? Далее говорим только об URL-ах, прошедших список "Только из кэша" с результатом "нет".
1. Каждый URL, физически отсутствующий в кэше, получает лишнюю проверку - прогон через список "Не обновлять" (это МИНУС; равен времени прогона такого URL через список "Не обновлять" в оперативной памяти).
2. Каждый URL, отсутствующий в списке "Не обновлять" либо имеющий критерий свежести равный 0, перестает проверяться на физическое наличие его в кэше (это ПЛЮС; равен времени прогона такого URL через список "Преобразование URL" в оперативной памяти и внутреннюю процедуру программы, формирующую из URL путь к файлу операционной системы, для получения его истинного адреса в кэше, а также времени ответа на вопрос о наличии файла в кэше (физический доступ к файловой системе либо загрузка через RAM-кэш).
Это, пожалуй, менее голословно.
Может, кто-нибудь теперь оценит, стоит ли овчина выделки?

Цитировать
список "Не обновлять" в последней версии проверяется не только при наличии файла в кэше! Это необходимо для правильного формирования ответа "304", когда это необходимо
Это хорошо придумано! Но как это влияет на обсуждаемую тему?
« Последнее редактирование: 17 января 2007, 00:51:01 от Михаил » Сообщить модератору   Записан
Кирилл
Beta tester
*****

Репутация: +5/-1
Offline Offline

Сообщений: 124


« Ответ #12 : 17 января 2007, 08:11:07 »

2 Михаил
Наличие файла в кеше надо проверять в любом случае, исключая разве что черный список и переадресацию. Для файла, который есть в кеше, надо добавить параметр If-Modified-Since в заголовок и узнать, какую дату-время туда вписывать.
Сообщить модератору   Записан
DenZzz
Модератор
*****

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

Сообщений: 5589



« Ответ #13 : 17 января 2007, 08:58:00 »

Михаил

Цитировать
Опубликуй, пожалуйста, результаты замеров, полученные в ходе этого "неголословного" исследования.


С одной стороны, данные о времени загрузки файлов с диска и из RAM-кэша нам дает сам HC в отладочной информации. Там можно заметить, что во время "простоя" системы разница не велика 1-2 ms, но во время интенсивного использования диска другими программами выигрыш возрастает до нескольких десятков ms. Вопрос: это много это или мало?

Тест эффективности RAM-кэша не так давно проводил mai62. Но тогда не ставилось целью замерить уменьшение времени загрузки...

Тогда я провел другой эксперимент - сохранил в браузере сессию из 30 страниц, перевел HC в автономный режим и стал загружать эту сессию по 3 раза с включенным RAM-кэшем и отключенным. Результаты отличались на какие-то жалкие доли секунды, сравнимые с погрешностью измерений!

Мы обсудили тогда этот вопрос с mai62 по мылу и пришли к такому выводу:
Цитировать
Эта  экономия  нивелируется  на  фоне  остального  времени  работы. По
графику  загрузки процессора же видно, что экономия небольшая. И потом
на  скорость  загрузки  еще влияет браузер, он же не все запросы сразу
выстреливает, а мо мере отображения предыдущих.
Еще  сделал такой эксперимент. Включил опцию Не показывать в мониторе.
Время загрузки уменьшилось процентов на 20

Поэтому не надо говорить, что:
Цитировать
Да, практических проверок не было.
Сообщить модератору   Записан
Михаил
Gold beta tester
*****

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

Сообщений: 5511



« Ответ #14 : 17 января 2007, 13:01:36 »

Кирилл
Цитировать
Наличие файла в кеше надо проверять в любом случае, исключая разве что черныйрограммы список и переадресацию. Для файла, который есть в кеше, надо добавить параметр If-Modified-Since в заголовок и узнать, какую дату-время туда вписывать.
Убедительно. Это основание лезть в кэш я упустил.
Одна голова хорошо... а с туловищем - лучше :-)

Предлагаю считать тему закрытой отклонением первоначального предложения.

P.S. 1. Кстати, а почему на форуме нет условного обозначения для закрытой темы?
       2. Как выясняется, тема возникла от того, что блок-схема из ФАКа отражает общую логику работы списков, но не отражает всю логику работы НС. Предлагаю для прояснения в собственных головах и умах последователей изготовить полную схему. Готов взять сие на себя, если поддержите.
Сообщить модератору   Записан
Rick
Администратор
*****

Репутация: +15/-1
Offline Offline

Сообщений: 868


WWW
« Ответ #15 : 17 января 2007, 13:43:16 »

Михаил
Цитировать
Предлагаю считать тему закрытой отклонением первоначального предложения.
Коли так - пооффтопю. Улыбка

Цитировать
1. Кстати, а почему на форуме нет условного обозначения для закрытой темы?
А чем закрытая тема должна отличаться от заблокированной? По смыслу и условному обозначению?

Цитировать
Предлагаю для прояснения в собственных головах и умах последователей изготовить полную схему. Готов взять сие на себя, если поддержите.
Почему бы и нет. Только чем подробнее схема - тем больше вероятность, что ее придется часто править при обновлениях HC.

Добавлено:
Тема остается открытой - вдруг у кого-то появится новый взгляд на предложенное.
« Последнее редактирование: 17 января 2007, 13:47:00 от Rick » Сообщить модератору   Записан
DenZzz
Модератор
*****

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

Сообщений: 5589



« Ответ #16 : 17 января 2007, 13:45:47 »

Михаил

Цитировать
2. Как выясняется, тема возникла от того, что блок-схема из ФАКа отражает общую логику работы списков, но не отражает всю логику работы НС.

Схема в ФАКе и не претендовала на доскональную точность! Она создавалась для новичков, чтобы иллюстрировать порядок и смысл работы списков, т.е. чтобы им было проще понять, когда файл берется из кэша HC, а когда грузится из Инета. Этого мы и добивались в схеме...

Цитировать
Предлагаю для прояснения в собственных головах и умах последователей изготовить полную схему. Готов взять сие на себя, если поддержите.

Пожалуйста, рисуй! Кто ж против... Если схема выйдет удачной, закину ссылку в ФАК.

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

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

Сообщений: 5511



« Ответ #17 : 17 января 2007, 14:30:23 »

Цитировать
Пожалуйста, рисуй! Кто ж против... Если схема выйдет удачной, закину ссылку в ФАК.
А разве речь шла о ФАКе? Зачем ее закидывать в ФАК, если он создается для новичков? Разве она относится к часто задаваемым вопросам? Разве их интересует, как работает If-Modified-Since или RAM-кэш, например?
Нет, это, на мой взгляд, больше нужно именно для "программистов" (хотящих написать плагин, например) или для продвинутых пользователей (выжать максимум возможностей). Это для включения в документацию.
Сообщить модератору   Записан
DenZzz
Модератор
*****

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

Сообщений: 5589



« Ответ #18 : 17 января 2007, 15:25:13 »

Михаил

Нарисуй и выложи на форуме для обсуждения! Потом закину в Документацию...
Сообщить модератору   Записан
mai62
Автор HC
*****

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

Сообщений: 6383


« Ответ #19 : 17 января 2007, 15:52:49 »

Думаю любой желающий может написать статью по теме НС и после рассмотрения модератором она может быть выложена в раздел Документация (или сделаем раздел Статьи).
Сообщить модератору   Записан
Страниц: [1]   Вверх
  Отправить эту тему    Печать  

 
Перейти в: