Название: Неоптимальность порядка проверки списков Отправлено: Михаил от 14 января 2007, 16:42:19 Список условных прокси проверяется до всех остальных (по крайней мере до черного, белый и переадресацию проверять было лень). А по логике должен бы проверяться лишь после принятия окончательного решения о загрузке из Интернет (т.е. по блок-схеме сразу после ухода на ветку "нет" условия "Файл в Интернете большой?"). В результате исключим лишние проверки этого списка в случаях, когда в Интернет не лезем. Соответственно при этом уйдет ненужная информация о срабатывании этого списка из монитора.
Просьба обсудить. Если все так и есть - то в ToDo. Название: Re: Неоптимальность порядка проверки списков Отправлено: Дем от 14 января 2007, 18:01:12 Ну вообще условие "Файл в Интернете большой?" проверяется уже после начала загрузки, а вообще мысль правильная...
Название: Re: Неоптимальность порядка проверки списков Отправлено: Михаил от 14 января 2007, 18:28:01 Согласен, надо до проверки условия "Файл в Интернете большой?"
Название: Re: Неоптимальность порядка проверки списков Отправлено: DenZzz от 14 января 2007, 21:15:56 Михаил
Цитировать В результате исключим лишние проверки этого списка в случаях, когда в Интернет не лезем. Соответственно при этом уйдет ненужная информация о срабатывании этого списка из монитора. А чем мешает эта информация? Думаешь, это ускорит работу? Сомневаюсь... Кстати, сейчас попытал список "Условных прокси" при загрузке одного и того же блокируемого URL - информация, что УП сработал появляется в Мониторе только при первой блокировке, а потом уже нет! Название: Re: Неоптимальность порядка проверки списков Отправлено: Михаил от 15 января 2007, 09:18:25 Важнее, что это перестанет засорять монитор ненужными ссылками на срабатывание правила, которое не используется. Ну и ускоримся слегка тоже - проверяем на один список меньше.
Название: Небольшая оптимизация Отправлено: Михаил от 16 января 2007, 18:16:40 В FAQ (http://handycache.ru/component/option,com_simplefaq/task,display/Itemid,3/catid,1/#FAQ12) имеется достаточно наглядная блок-схема работы НС.
Посмотрев ее, предлагаю обсудить пару оптимизаций. 1. После загрузки из Интернета грузить объект в браузер не после проверки списка "Запись в кэш", а непосредственно перед этим. Результат - маленькое, но приятное ускорение дохождения данных до наших глаз + маленькое сокращение количества линий в схеме. 2. При отсутствии URL в списке "Только из кэша" мы сразу идем копаться в кэше. Однако если его нет и в "Не обновлять", то мы все равно его скачиваем из интернета. Так чего же мы зря теряли время и шерстили кэш? В связи с этим проверку наличия файла в кэше лучше делать ПОСЛЕ обработки списка "Не обновлять". Только для этого надо реализовать постпроверку критерия свежести. В качестве плюса имеем избегание лишних обращений к кэшу. Минусом же является пропорциональное увеличение количества обработок списка "Не обновлять". Однако первое делается посредством обращения к диску и поиском в зачастую огромном кэше, второе - только в памяти и в несравненно меньших объемах. Итоговый вид схемы привел во вложении. Я сознательно не рисовал проверку размера файла как не относящуюся к данной теме. Давайте обсудим... Название: Re: Небольшая оптимизация Отправлено: DenZzz от 16 января 2007, 22:19:05 Михаил
Цитировать 1. После загрузки из Интернета грузить объект в браузер не после проверки списка "Запись в кэш", а непосредственно перед этим. Результат - маленькое, но приятное ускорение дохождения данных до наших глаз + маленькое сокращение количества линий в схеме. Во-первых, так и происходит! HC начинает качать новый объект, получает заголовки с первой порцией файла, отдает ее браузеру и ОДНОВРЕМЕННО проверяет список "Запись в кэш", чтобы определить, надо ли ПАРАЛЛЕЛЬНО писать файл в кэш или нет. Ускорять здесь нечего! Во-вторых, ты постоянно говоришь о каком-то мифическом ускорении от сокращения числа списков и правил, но вынужден тебя огорчить, заметного ускорения не получится, это уже было раз проверено и даже описано в ФАКе (http://handycache.ru/component/option,com_simplefaq/task,display/Itemid,3/catid,1/#FAQ23)! Цитировать В качестве плюса имеем избегание лишних обращений к кэшу. Минусом же является пропорциональное увеличение количества обработок списка "Не обновлять". Однако первое делается посредством обращения к диску и поиском в зачастую огромном кэше, второе - только в памяти и в несравненно меньших объемах. Проверка наличия файла в огромном кэше занимает не так много времени, как может показаться, т.к. HC точно знает, где искать! У него есть точный путь! Возможный выигрыш в скорости нивелируется двойной проверкой списка "Не обновлять"! К тому же, у HC есть RAM-кэш, в который записываются файлы, раз прочитанные из дискового кэша в текущем сеансе, и повторного обращения к диску за этими файлами уже не происходит! Проверка наличия и свежести этих файлов при 2 и следующих обращениях производятся только в памяти! Цитировать Итоговый вид схемы привел во вложении. Где ветка "НЕТ" из списка "Запись в кэш" и куда она ведет? Название: Re: Небольшая оптимизация Отправлено: Михаил от 16 января 2007, 22:34:00 Цитировать Во-первых, так и происходит! Значит, надо изменить неправильную схему в FAQЦитировать Возможный выигрыш в скорости нивелируется двойной проверкой списка "Не обновлять"! Ты веришь в то, что говоришь? Зачем же RAM-кэш создан, еслиЦитировать Проверка наличия файла в огромном кэше занимает не так много времени, как может показаться Исключить такую проверку - это как раз одна из его функций, как я понимаю.Цитировать Где ветка "НЕТ" из списка "Запись в кэш" и куда она ведет? Ветки "НЕТ" нет (неплохой каламбур), потому что если запись в кэш не нужна, то дальше ничего не происходит.Название: Re: Небольшая оптимизация Отправлено: DenZzz от 16 января 2007, 22:52:13 Михаил
Цитировать Значит, надо изменить неправильную схему в FAQ Это не схема неправильная, это ты ее неправильно понимаешь! Схема логически верна в плане итогового результата и не претендует на точный алгоритм работы кода программы! Блок проверки размера файла тоже нарисован не там, где он на самом деле есть, но это сознательно сделано для наглядности и простоты понимания логики работы HC... Цитировать Зачем же RAM-кэш создан, если Цитировать Проверка наличия файла в огромном кэше занимает не так много времени, как может показаться В первую очередь, чтобы ускорить ПОВТОРНОЕ ЧТЕНИЕ из кэша файлов и проверки их СВЕЖЕСТИ, а не просто для проверки их наличия... Кстати, еще было предложение создавать индексы кэша, но остановились на RAM-кэше, возможно, пока... Название: Re: Небольшая оптимизация Отправлено: Михаил от 16 января 2007, 23:08:48 DenZzz
Схемы обычно понимаются так, как они нарисованы, а не так как они мыслятся в чьей-то голове, доступа к которой из форума у меня нет. А теперь ответь по существу (в скобках - мои ответы): 1. Имеет ли место экономия в случае реализации п.2 из заголовка темы? (да, и существенная, поскольку часть файлов будет пущена в обход проверки их существования в кэше, которое реализуется в БОЛЬШИНСТВЕ случаев доступом к диску). 2. Если да, то какова сложность реализации? (близка к нулю). Так в чем же тогда проблема? Название: Re: Небольшая оптимизация Отправлено: DenZzz от 16 января 2007, 23:32:18 Михаил
Цитировать 1. Имеет ли место экономия в случае реализации п.2 из заголовка темы? Какая-то экономия возможно и будет, НО двойная проверка списка "Не обновлять" дает обратный эффект! В итоге, экономия вряд ли будет заметна "на глаз"! Цитировать да, и существенная Насчет "существенная" - у тебя есть какие-то результаты замеров времени проверки наличия файла в кэше? Это утверждение голословно! Вряд ли итоговый выигрыш превысит несколько миллисекунд, неразличимых на глаз! Еще замечу, что список "Не обновлять" в последней версии проверяется не только при наличии файла в кэше! Это необходимо для правильного формирования ответа "304", когда это необходимо (см. здесь (http://handycache.ru/component/option,com_smf/Itemid,10/topic,91.msg625/#msg625)). Цитировать 2. Если да, то какова сложность реализации? Это вопрос к mai62, а не ко мне! Название: Re: Небольшая оптимизация Отправлено: Михаил от 17 января 2007, 00:25:43 Цитировать Возможный выигрыш в скорости нивелируется двойной проверкой списка "Не обновлять"! Опубликуй, пожалуйста, результаты замеров, полученные в ходе этого "неголословного" исследования.Цитировать Это утверждение голословно! Да, практических проверок не было. Давай сделаем это хотя бы частично в уме. Во-первых, сразу оговоримся, что никакой "двойной проверки" списка "Не обновлять" нет и в помине. Проверка как была, так и есть одна. В чем же получается разница? Далее говорим только об URL-ах, прошедших список "Только из кэша" с результатом "нет".1. Каждый URL, физически отсутствующий в кэше, получает лишнюю проверку - прогон через список "Не обновлять" (это МИНУС; равен времени прогона такого URL через список "Не обновлять" в оперативной памяти). 2. Каждый URL, отсутствующий в списке "Не обновлять" либо имеющий критерий свежести равный 0, перестает проверяться на физическое наличие его в кэше (это ПЛЮС; равен времени прогона такого URL через список "Преобразование URL" в оперативной памяти и внутреннюю процедуру программы, формирующую из URL путь к файлу операционной системы, для получения его истинного адреса в кэше, а также времени ответа на вопрос о наличии файла в кэше (физический доступ к файловой системе либо загрузка через RAM-кэш). Это, пожалуй, менее голословно. Может, кто-нибудь теперь оценит, стоит ли овчина выделки? Цитировать список "Не обновлять" в последней версии проверяется не только при наличии файла в кэше! Это необходимо для правильного формирования ответа "304", когда это необходимо Это хорошо придумано! Но как это влияет на обсуждаемую тему?Название: Re: Небольшая оптимизация Отправлено: Кирилл от 17 января 2007, 08:11:07 2 Михаил
Наличие файла в кеше надо проверять в любом случае, исключая разве что черный список и переадресацию. Для файла, который есть в кеше, надо добавить параметр If-Modified-Since в заголовок и узнать, какую дату-время туда вписывать. Название: Re: Небольшая оптимизация Отправлено: DenZzz от 17 января 2007, 08:58:00 Михаил
Цитировать Опубликуй, пожалуйста, результаты замеров, полученные в ходе этого "неголословного" исследования. С одной стороны, данные о времени загрузки файлов с диска и из RAM-кэша нам дает сам HC в отладочной информации. Там можно заметить, что во время "простоя" системы разница не велика 1-2 ms, но во время интенсивного использования диска другими программами выигрыш возрастает до нескольких десятков ms. Вопрос: это много это или мало? Тест эффективности RAM-кэша не так давно проводил (http://forum.ru-board.com/topic.cgi?forum=5&topic=21354&start=600#12) mai62. Но тогда не ставилось целью замерить уменьшение времени загрузки... Тогда я провел другой эксперимент - сохранил в браузере сессию из 30 страниц, перевел HC в автономный режим и стал загружать эту сессию по 3 раза с включенным RAM-кэшем и отключенным. Результаты отличались на какие-то жалкие доли секунды, сравнимые с погрешностью измерений! Мы обсудили тогда этот вопрос с mai62 по мылу и пришли к такому выводу: Цитировать Эта экономия нивелируется на фоне остального времени работы. По графику загрузки процессора же видно, что экономия небольшая. И потом на скорость загрузки еще влияет браузер, он же не все запросы сразу выстреливает, а мо мере отображения предыдущих. Еще сделал такой эксперимент. Включил опцию Не показывать в мониторе. Время загрузки уменьшилось процентов на 20 Поэтому не надо говорить, что: Цитировать Да, практических проверок не было. Название: Re: Небольшая оптимизация Отправлено: Михаил от 17 января 2007, 13:01:36 Кирилл
Цитировать Наличие файла в кеше надо проверять в любом случае, исключая разве что черныйрограммы список и переадресацию. Для файла, который есть в кеше, надо добавить параметр If-Modified-Since в заголовок и узнать, какую дату-время туда вписывать. Убедительно. Это основание лезть в кэш я упустил.Одна голова хорошо... а с туловищем - лучше :-) Предлагаю считать тему закрытой отклонением первоначального предложения. P.S. 1. Кстати, а почему на форуме нет условного обозначения для закрытой темы? 2. Как выясняется, тема возникла от того, что блок-схема из ФАКа отражает общую логику работы списков, но не отражает всю логику работы НС. Предлагаю для прояснения в собственных головах и умах последователей изготовить полную схему. Готов взять сие на себя, если поддержите. Название: Re: Небольшая оптимизация Отправлено: Rick от 17 января 2007, 13:43:16 Михаил
Цитировать Предлагаю считать тему закрытой отклонением первоначального предложения. Коли так - пооффтопю. :)Цитировать 1. Кстати, а почему на форуме нет условного обозначения для закрытой темы? А чем закрытая тема должна отличаться от (http://handycache.ru/forum/Themes/SlickPro_Graphite/images/icons/quick_lock.gif) заблокированной? По смыслу и условному обозначению?Цитировать Предлагаю для прояснения в собственных головах и умах последователей изготовить полную схему. Готов взять сие на себя, если поддержите. Почему бы и нет. Только чем подробнее схема - тем больше вероятность, что ее придется часто править при обновлениях HC.Добавлено: Тема остается открытой - вдруг у кого-то появится новый взгляд на предложенное. Название: Re: Небольшая оптимизация Отправлено: DenZzz от 17 января 2007, 13:45:47 Михаил
Цитировать 2. Как выясняется, тема возникла от того, что блок-схема из ФАКа отражает общую логику работы списков, но не отражает всю логику работы НС. Схема в ФАКе и не претендовала на доскональную точность! Она создавалась для новичков, чтобы иллюстрировать порядок и смысл работы списков, т.е. чтобы им было проще понять, когда файл берется из кэша HC, а когда грузится из Инета. Этого мы и добивались в схеме... Цитировать Предлагаю для прояснения в собственных головах и умах последователей изготовить полную схему. Готов взять сие на себя, если поддержите. Пожалуйста, рисуй! Кто ж против... Если схема выйдет удачной, закину ссылку в ФАК. Но только не забывай, что ФАК создается для новичков (не программистов!), которые недавно поставили HC и не знают, что и как! Поэтому новая схема должна быть понятна в первую очередь им, а не группе "посвященных"... Название: Re: Небольшая оптимизация Отправлено: Михаил от 17 января 2007, 14:30:23 Цитировать Пожалуйста, рисуй! Кто ж против... Если схема выйдет удачной, закину ссылку в ФАК. А разве речь шла о ФАКе? Зачем ее закидывать в ФАК, если он создается для новичков? Разве она относится к часто задаваемым вопросам? Разве их интересует, как работает If-Modified-Since или RAM-кэш, например?Нет, это, на мой взгляд, больше нужно именно для "программистов" (хотящих написать плагин, например) или для продвинутых пользователей (выжать максимум возможностей). Это для включения в документацию. Название: Re: Небольшая оптимизация Отправлено: DenZzz от 17 января 2007, 15:25:13 Михаил
Нарисуй и выложи на форуме для обсуждения! Потом закину в Документацию... Название: Re: Небольшая оптимизация Отправлено: mai62 от 17 января 2007, 15:52:49 Думаю любой желающий может написать статью по теме НС и после рассмотрения модератором она может быть выложена в раздел Документация (или сделаем раздел Статьи).
Powered by SMF 1.1.3 SMF © 2006, Simple Machines LLC
Joomla Bridge by JoomlaHacks.com |