Название: Пытаться экономить путем предугадывания Отправлено: Михаил от 13 февраля 2007, 00:40:21 Как бы тщательно мы не задавали в "Не обновлять" правила, стараясь перекрыть ими максимальный диапазон типов данных, остается множество редко обновляющихся данных:
- неучтенных нами типов (например, нестандартно заданных); - учтенных типов, но на ряде сайтов ведущих себя по-иному (например, html на старых необновляемых сайтах тоже не обновляется). В этом случае нас спасает механизм проверки If-Modified-Since. Не изменившиеся файлы не запрашиваются повторно, а берутся из кэша. Но соединение с удаленным сервером мы в этом случае все же устанавливаем, затрачивая на это время/трафик. А что, если ввести такой опциональный режим НС: Для пишущегося в кэш URL с непустым полем Last-Modified сравниваем значение этого поля с текущей датой. Допустим, разница между ними равна t. Тогда до времени T = "текущая дата + t/15 (или t/10)" вероятность обновления этого URL на сервере мала (например, если файл не обновлялся год, то он с большой долей вероятности не будет обновляться еще месяц). Значит, до времени T на каждую попытку загрузки из сети мы будем вместо запроса к серверу If-Modified-Since просто брать файл из кэша. В результате исключим значительное число проверок If-Modified-Since на удаленном сервере для URL, не обновляющихся значительный период времени. Вопрос, где хранить это время T. Может, в индексе. Давайте обсудим... Название: Re: Пытаться экономить путем предугадывания Отправлено: DenZzz от 13 февраля 2007, 01:14:28 В этом случае нас спасает механизм проверки If-Modified-Since. Не изменившиеся файлы не запрашиваются повторно, а берутся из кэша. Но соединение с удаленным сервером мы в этом случае все же устанавливаем, затрачивая на это время/трафик. Эти затраты времени/трафика не так уж и велики, т.к. передаются/принимаются только заголовки. Цитировать В результате исключим значительное число проверок If-Modified-Since на удаленном сервере для URL, не обновляющихся значительный период времени. Если пользователь снова зашел на этот статичный сайт в он-лайн, то он, вероятно, надеется увидеть его обновленные страницы или хотя бы проверить, а не обновились ли они! Иначе, он бы воспользовался автономным режимом или правилом .* в списке "Не обновлять". Предлагаемая опция не позволит ему это сделать, введя в заблуждение! Цитировать Вопрос, где хранить это время T. Может, в индексе. Индекса пока нет и неизвестно, когда будет, если будет вообще... Название: Re: Пытаться экономить путем предугадывания Отправлено: Михаил от 13 февраля 2007, 01:27:37 DenZzz
Цитировать Эти затраты времени/трафика не так уж и велики, т.к. передаются/принимаются Времени - зависит от качества соединения. Трафика - курочка по зернышку...только заголовки. Цитировать Предлагаемая опция не позволит ему это сделать, введя в заблуждение! Не более, чем вводят его в заблуждение URL-ы, просеянные через список "Не обновлять".Я ж предлагаю опционально. Т.е. есть сомнения - отключи чтение из кэша и смотри заведомо свежий вариант (собственно, то же самое делаем и при использовании списков "Не обновлять" и "Только из кэша"). Цитировать Индекса пока нет и неизвестно когда будет, если будет вообще... Это реальное препятствие. Пусть эта тема будет дополнительным толчком к продвижению идеи создания индекса.Название: Re: Пытаться экономить путем предугадывания Отправлено: DenZzz от 13 февраля 2007, 08:32:33 Не более, чем вводят его в заблуждение URL-ы, просеянные через список "Не обновлять". Более! Когда включено правило .* в списке "Не обновлять" или автономный режим, то пользователь заранее на 100% знает, что файл возьмется из кэша. А если включена предлагаемая тобой опция, то результат он заранее предвидеть не может, т.к. не знает, какое там сохранено время Т ! Возможно, ему даже придется повторно обновлять страницу с отключенной опцией! Также опция будет вредить, если ты зашел на сайт незадолго до его редкого обновления, но вынужден будешь теперь до времени Т смотреть копию из кэша! Только не говори, что можно просто отключить эту опцию - зачем нужна такая опция, которую надо отключать в большинстве случаев?! А много ты знаешь популярных сайтов, которые не обновляются месяцами? Если сайты обновляются регулярно или имеют динамический формируемый контент, как, например, на этом форуме и сайте, то предлагаемая тобой опция бесполезна! Название: Re: Пытаться экономить путем предугадывания Отправлено: NothingAnother от 13 февраля 2007, 08:36:03 вероятность обновления этого URL на сервере мала (например, если файл не обновлялся год, то он с большой долей вероятности не будет обновляться еще месяц) С точки зрения статистики - утверждение в корне неверное. Чтобы рассуждать о вероятности изменения (т.е. временнОй интерполяции), надо определить тенденцию, т.е. требуется информация о как минимум двух (правильнее - 3-х) предыдущих промежутках между обновлениямиЦитировать Трафика - курочка по зернышку... Эти зёрнышки просто утонут на фоне ICMP-флуда между тобой и провом, и чтобы не оперировать предположительными категориями - предлагаю проверить самому на практике (для усреднения, суммируя где-нибудь за месяц)Цитировать Я ж предлагаю опционально. Т.е. есть сомнения - отключи чтение из кэша и смотри заведомо свежий вариант (собственно, то же самое делаем и при использовании списков "Не обновлять" и "Только из кэша") Если речь идёт о контенте информационного характера (ты речь вёл о HTML), сомненья есть всегда - как уже сказал DenZzz для того чел и смотрит этот ресурс в онлайн, чтобы развеять свои сомнения. А для неинформативных типов - мы сами знаем, как часто это надо обновлять, что и реализуем в виде правил в упомянутых тобой спискахНазвание: Re: Пытаться экономить путем предугадывания Отправлено: Михаил от 13 февраля 2007, 11:05:54 DenZzz
Цитировать Более! Когда включено правило .* в списке "Не обновлять" или автономный режим, то пользователь заранее на 100% знает, что файл возьмется из кэша. Он что, для каждого файла в уме отсчитывает, сколько осталось критерию свежести действовать? Нет, он никак не уверен в свежести контента, определенного с критерием свежести. А причем тут автономный режим?Цитировать Также опция будет вредить, если ты зашел на сайт незадолго до его редкого обновления, но вынужден будешь теперь до времени Т смотреть копию из кэша! Но ведь с использованием критерия свежести мы получаем то же самое! Почему это не пугает?Цитировать А много ты знаешь популярных сайтов, которые не обновляются месяцами? А почему сайтов? Конкретные необновляемые файлы есть практически на любом сайте.Цитировать Если сайты обновляются регулярно или имеют динамический формируемый контент, как, например, на этом форуме и сайте, то предлагаемая тобой опция бесполезна! Тогда Т будет исчисляться секундами/долями секунды и все будет обновляться. А вот критерий свежести в "Не обновлять" такому контенту обновиться как раз не даст - надо писать исключение.NothingAnother Цитировать Эти зёрнышки просто утонут на фоне ICMP-флуда между тобой и провом, и чтобы не оперировать предположительными категориями - предлагаю проверить самому на практике (для усреднения, суммируя где-нибудь за месяц) И тем не менее - эти зернышки есть и реальные. А что насчет времени при медленных/глючных соединениях?Цитировать С точки зрения статистики - утверждение в корне неверное. Чтобы рассуждать о вероятности изменения (т.е. временнОй интерполяции), надо определить тенденцию, т.е. требуется информация о как минимум двух (правильнее - 3-х) предыдущих промежутках между обновлениями Я разве говорил, что опирался на статистику? Это рассуждение не взято с потолка. Оно получается обоснованным с определенной существенной вероятностью. Оценивая в уме вероятность чего-либо, не обязательно пользоваться статистикой - часто нужно и логикой (например, наша оценка как высокой вероятности того, что выпав из машины на ходу человек получит травму, обоснована не статистикой, а именно логикой). А если мы подключим статистику и будем брать 3 измерения, то вероятность просто увеличится и будем оперировать например величиной не t/15, а t/10. Но для нас это не всегда достижимо, т.к. до 3 измерений мы можем просто не дожить. Но в принципе, что мешает нам накапливать результат измерений и повышать вероятность?Фактически, мы добавляем в НС толику интеллекта. Цитировать А для неинформативных типов - мы сами знаем, как часто это надо обновлять, что и реализуем в виде правил в упомянутых тобой списках Мы - это, видимо, давние (продвинутые) пользователи. А как насчет неразбирающихся? Откуда знают они?А давние пользователи в отношении информации, приведенной мной в первом посте?: - неучтенных нами типов (например, нестандартно заданных); - учтенных типов, но на ряде сайтов ведущих себя по-иному (например, чаще чем обычно обновляющиеся рисунки/скрипты и т.п.). Цитировать Если речь идёт о контенте информационного характера (ты речь вёл о HTML), сомненья есть всегда - как уже сказал DenZzz для того чел и смотрит этот ресурс в онлайн, чтобы развеять свои сомнения. А для неинформативных типов - мы сами знаем, как часто это надо обновлять, что и реализуем в виде правил в упомянутых тобой списках А как насчет частоупотребимых правил типа .\.*html$ с критерием свежести 2 мин. В чем мы уверены тогда? Мы допускаем это осознанно. А в "моем" случае допускать это будет НС на основании предварительных измерений с гораздо более высокой вероятностью. И там, где последнее обновление произошло через 5 мин., он в первый раз выдаст свежий файл через 20 сек (а не 2 мин), фактически гарантируя эту свежесть. А в последующие разы будет учитывать статистику и повышать вероятность. Название: Re: Пытаться экономить путем предугадывания Отправлено: DenZzz от 13 февраля 2007, 12:51:28 Михаил
Цитировать Он что, для каждого файла в уме отсчитывает, сколько осталось критерию свежести действовать? Нет, он никак не уверен в свежести контента, определенного с критерием свежести. А причем тут автономный режим? У некоторых в правиле .* списка "Не обновлять" стоит заведомо большое значение, чтобы это правило всегда срабатывало! Зачем? Прочти вот в этой теме (http://handycache.ru/component/option,com_smf/Itemid,10/topic,203.0/)... Причем тут автономный режим? Это аналог правила .* без критерия свежести в списке Н. Когда мне надо взять страницу заведомо из кэша, я нажимаю горячую клавишу включения автономного режима и вообще не парюсь с правилами в списке "Н"! Так что, считать время действия критерия свежести мне в уме не надо! Цитировать Цитировать Также опция будет вредить, если ты зашел на сайт незадолго до его редкого обновления, но вынужден будешь теперь до времени Т смотреть копию из кэша! Но ведь с использованием критерия свежести мы получаем то же самое! Почему это не пугает?Нет, не то же! В списке Н правила с критерием свежести у меня написаны с таким расчетом, что не будут определенное время обновляться только те данные, свежестью которых я могу пренебречь! А твоя опция будет срабатывать на все URL, даже на те, проверять свежесть которых для меня актуально! Только не предлагай писать исключения к твоей опции! Это невозможно! Я точно могу описать типы URL того, что мне надо не обновлять, но предусмотреть все варианты URL динамического контента невозможно! Цитировать Цитировать А много ты знаешь популярных сайтов, которые не обновляются месяцами? А почему сайтов? Конкретные необновляемые файлы есть практически на любом сайте.Например? Картинки - и без того входят в список Н без критерия свежести! Скрипты и стили - также в Н и проверяются с учетом критерия. Архивы, музыка, программы и т.п. качаются 1 раз, либо очень редко повторно! Что еще осталось статического? Цитировать Цитировать Если сайты обновляются регулярно или имеют динамический формируемый контент, как, например, на этом форуме и сайте, то предлагаемая тобой опция бесполезна! Тогда Т будет исчисляться секундами/долями секунды и все будет обновляться.Так вот я и говорю - бесполезна! ;) Придется для каждого загружаемого файла подсчитывать и хранить где-то время Т, а работать оно будет очень редко! Какой смысл? Цитировать А вот критерий свежести в "Не обновлять" такому контенту обновиться как раз не даст - надо писать исключение. Просто в списке Н не должно быть правил для динамического контента! У меня их нет! А у кого есть, значит он сделал это сознательно и специально - для него важнее экономия, а не актуальность данных! Цитировать например, наша оценка как высокой вероятности того, что выпав из машины на ходу человек получит травму, обоснована не статистикой, а именно логикой А на чем основана наша логика? Как раз на нашем опыте, т.е. накопленных эмпирических знаниях! Следовательно, все на той же статистике! Например, я могу на 100% утверждать, что в июле средняя температура в моем городе будет выше 20 градусов Цельсия! Это логичное заявление я могу сделать на основе своего опыта (статистики)! И в то же время я ничего не могу сказать о средней температуре на Венере в этом месяце, т.к. просто не интересовался и не собирал данные! Цитировать Мы - это, видимо, давние (продвинутые) пользователи. А как насчет неразбирающихся? Откуда знают они? А давние пользователи в отношении информации, приведенной мной в первом посте? Неразбирающиеся используют дефолтные списки или списки опытных! А опытные пишут правила в список Н, исходя не из разовых наблюдений за датой изменения, а из опыта (статистики) изменения конкретных данных в течение некоторого времени! Цитировать А как насчет частоупотребимых правил типа .\.*html$ с критерием свежести 2 мин. В чем мы уверены тогда? В том, что в течение 2-х минут после последней загрузки страницы, она будет браться из кэша, а уже через 2 минуты ее свежесть будет проверяться на сервере! Это логично и ожидаемо! Цитировать А в "моем" случае допускать это будет НС на основании предварительных измерений с гораздо более высокой вероятностью. Не согласен, что из одной даты последнего обновления страницы можно сделать вывод "с гораздо более высокой вероятностью" о времени ее следующего обновления! Это все равно, что гадать на кофейной гуще! Вероятность невозможно посчитать без статистики! А ее, как ты заметил, может и не быть! Да и собрать статистику по каждому URL автоматически не просто: ее надо где-то хранить, обрабатывать, анализировать и т.д. Название: Re: Пытаться экономить путем предугадывания Отправлено: Михаил от 13 февраля 2007, 18:48:31 DenZzz
Пользователь пишет критерий свежести, исходя из неких собственных понятий относительно устаревания типов данных. Если б он располагал реальной информацией о том, что рисунки на некоем сайте обновляются чуть ли не раз в минуту, на другом - последний раз - год назад, а на третьем - еще с другой периодичностью, я думаю, он бы использовал эту информацию для соответствующей корректировки списка "Не обновлять". Но пользователь или не знает этой информации, или физически не может ее учесть для каждого конкретного сайта. А вот НС знает и потенциально учесть может. Цитировать Не согласен, что из одной даты последнего обновления страницы можно сделать вывод "с гораздо более высокой вероятностью" о времени ее следующего обновления! Это все равно, что гадать на кофейной гуще! Вывод не делается. Делается предположение/допущение, но не о времени следующего обновления страницы, а о вероятности ее необновления за период, в 15 раз меньший, чем фактически прошедший период "статичности". На мой взгляд, вполне логичное предположение. А дальше его можно еще больше улучшать, используя статистику (опять же потенциально).Не хочется спорить о логике и статистике. Попробую тогда так: мы провели 15 статистических испытаний, в течение которых контент не поменялся. На основании этого мы предполагаем, что он не поменяется во время проведения 16-го. Так, если котент не менялся в течение каждого из предыдущих 15 месяцев, то мы с приличной вероятностью прогнозируем его неизменность в течение следующего месяца. Название: Re: Пытаться экономить путем предугадывания Отправлено: NothingAnother от 13 февраля 2007, 19:57:35 Пользователь пишет критерий свежести, исходя из неких собственных понятий относительно устаревания типов данных Ну, с этим трудно спорить!.. ;)Цитировать Если б он располагал реальной информацией о том, что рисунки на некоем сайте обновляются чуть ли не раз в минуту, на другом - последний раз - год назад, а на третьем - еще с другой периодичностью, я думаю, он бы использовал эту информацию для соответствующей корректировки списка "Не обновлять" А с этим спорить легко! :P Уж коль важна актуальность рисунков - им нечего делать в "Не обновлять" - на эту задачу и без всяких прогнозов надёжно работает If-Modified-Since. Пример явно неудачныйЦитировать пользователь или не знает этой информации, или физически не может ее учесть для каждого конкретного сайта. А вот НС знает и потенциально учесть может.Вывод не делается. Делается предположение/допущение, но не о времени следующего обновления страницы, а о вероятности ее необновления за период, в 15 раз меньший, чем фактически прошедший период "статичности" А на каком основании делается это допущение?! И откуда взято "15"?? Почему не 3.1415926, 13, 33 и т.д.?? Так левая нога захотела? ;) Вот тебе пример - есть такой "FlashGet" - период (млин, какой ещё там период?!) обновления страницы - то более полугода без изменений, то за 2 дня 3 версии, потом опять тишина... И теперь, по твоему прогнозу (на основании длительного затишья) обновление мне окажется доступным через 20 дней? Нет уж, увольте!.. >:(Название: Re: Пытаться экономить путем предугадывания Отправлено: Михаил от 13 февраля 2007, 20:38:01 Цитировать Уж коль важна актуальность рисунков - им нечего делать в "Не обновлять" - на эту задачу и без всяких прогнозов надёжно работает If-Modified-Since. А с этим спорить еще легче: работая без всяких прогнозов, If-Modified-Since лезет в интернет когда надо и когда не надо (последнее гораздо чаще).О чем спорим-то. Сам замысел в том, чтоб уменьшить количество этих обращений в сеть со стороны If-Modified-Since. А принимая крайность, противоположную твоей, можно сказать: "Уж коль рисунки не актуальны - им точно в "Не обновлять" делать нечего: в "Ч" или "Т" их!" При одном и другом раскладе как-то упускается из виду, что одни из них могут быть актуальными, другие - нет. Цитировать И откуда взято "15"?? Почему не 3.1415926, 13, 33 и т.д.?? Для "наработки статистики". Это я взял "на глазок". Хочешь, прими 100. Это не главное и обсуждаемо, главное - сам принцип.Название: Re: Пытаться экономить путем предугадывания Отправлено: NothingAnother от 13 февраля 2007, 21:23:12 замысел в том, чтоб уменьшить количество этих обращений в сеть со стороны If-Modified-Since Жертвовать надёжностью ожидаемого поведения сабжа ради подобой "экономии"?! Овчинка выделки не стОит! >:(Цитировать одни из них могут быть актуальными, другие - нет Актуальными/неактуальными для тебя или в смысле синхронности с кэшем? Если первое - любые прогнозы работают против тебя, т.к. могут запросто тебя же и надуть - "как два пальца об асфальт" ;) Если второе - прогнозы просто бессильны это определить просто по природе своей гипотетичностиЦитировать Для "наработки статистики". Это я взял "на глазок". Хочешь, прими 100 Статистику (похоже, ты просто не знаком с этой научной дисциплиной :-\) не наработаешь, подменяя её чёткие императивы произволом в виде субъективного представления "логичности". "Принять 100" я не хочу, как и любое другое значение просто из-за полного отсутствия каких бы то ни было предпосылок к подобному выборуНазвание: Re: Пытаться экономить путем предугадывания Отправлено: Михаил от 13 февраля 2007, 21:43:38 Цитировать Жертвовать надёжностью ожидаемого поведения сабжа ради подобой "экономии"?! Овчинка выделки не стОит! 1. Разумно жертвовать.2. Если б мы не жертвовали надежностью поведения сабжа в еще больших масштабах (имею ввиду списки "Н" и "Т"), я б может не предлагал бы такой вариант. Цитировать похоже, ты просто не знаком с этой научной дисциплиной ;)Выходит, я такой же невежа в статистике, как ты в логике. Каждому свое - всего не охватить. Приходится дополнять друг друга ;) Название: Re: Пытаться экономить путем предугадывания Отправлено: NothingAnother от 13 февраля 2007, 22:15:57 Разумно жертвовать Надеюсь, ты просто второпях забыл добавить "IMHO"Цитировать Выходит, я такой же невежа в статистике, как ты в логике Искренне рад, что у нас есть гуру (или сенсей? ???) логики, теперь хоть буду знать, к кому обращаться, если что - уж не откажи тогда невеже... ::)Цитировать Если б мы не жертвовали надежностью поведения сабжа в еще больших масштабах (имею ввиду списки "Н" и "Т") Вот именно этим - "надежностью поведения сабжа" мы как раз и не жертвуем т.к. пока что оно однозначно определяется нами же созданными правилами. Может, не стоит так уж упиваться собственной логичностью 8) а то упускаешь разницу между "надёжностью поведения программы" и надёжностью кэшированного контента :(Название: Re: Пытаться экономить путем предугадывания Отправлено: Михаил от 13 февраля 2007, 22:40:45 NothingAnother
Цитировать Надеюсь, ты просто второпях забыл добавить "IMHO" Да, мы оба торопимся в этом плане.Цитировать теперь хоть буду знать, к кому обращаться, если что - уж не откажи тогда невеже... Хорошо, когда каждый из нас может дополнить невежество другого. Давай совместим обе эти половины и получим полное (100% статистическое и следовательно, логическое) невежество ;)Может, не стоит так уж упиваться собственной логичностью а то упускаешь... Предлагаю в этом направлении остановиться, а то явно идем семимильными шагами. Цитировать Вот именно этим - "надежностью поведения сабжа" мы как раз и не жертвуем т.к. пока что оно однозначно определяется нами же созданными правилами. Как эта однозначность поможет тебе увидеть обновившийся скрипт, запрещенный тобой к обновлению в правиле списка "Н" или "Т"?Название: Re: Пытаться экономить путем предугадывания Отправлено: NothingAnother от 14 февраля 2007, 00:43:29 Как эта однозначность поможет тебе увидеть обновившийся скрипт, запрещенный тобой к обновлению в правиле списка "Н" или "Т"? Да при чём здесь "обновившийся скрипт"?? Однозначность в том и состоит это я - юзер задал такие правила поведения, и если внёс что-то в эти списки - стал быть мне маловажны эти обновления! Контент, актуальность которого мне важна в список "Т" не вносится!.. :oИ давай уже хватит ходить по кругу - резюмирую: я категорически против этого альтернативного "беззапросно гадающего" If-Modified-Since >:( Название: Re: Пытаться экономить путем предугадывания Отправлено: Михаил от 14 февраля 2007, 01:01:07 NothingAnother
Цитировать Контент, актуальность которого мне важна в список "Т" не вносится!.. А что насчет контента, вносимого тобой в "Н"? Как-то ты скромно умолчал... Какова для тебя его актуальность?Название: Re: Пытаться экономить путем предугадывания Отправлено: NothingAnother от 14 февраля 2007, 09:30:10 Как-то ты скромно умолчал... Какова для тебя его актуальность? И правда скромно... ::) Просто позволил себе смелость предположить (произвольно, не взвешивая вероятность ;)), что ты сам всё уже давно понял, и теперь просто развлекаешься, вынуждая вновь и вновь доказывать тебе очевидные вещи - без мощного статистического аппарата прогнозирование бессмысленно, а в нашем случае просто неприемлемо из-за чрезвычайно высокого фактора случайности (см. мой пример про FlashGet)...На этом своё участие в данном топике считаю законченным. Название: Re: Пытаться экономить путем предугадывания Отправлено: Михаил от 14 февраля 2007, 10:47:51 Цитировать Предлагаю в этом направлении остановиться, а то явно идем семимильными шагами. NothingAnotherЦитировать Просто позволил себе смелость предположить (произвольно, не взвешивая вероятность ), что ты сам всё уже давно понял, и теперь просто развлекаешься, вынуждая вновь и вновь доказывать тебе очевидные вещи С учетом того, что слова о культуре общения для тебя, видимо, пустой звук, очень приятно больше не видеть тебя в этом топике.Название: Re: Пытаться экономить путем предугадывания Отправлено: DenZzz от 14 февраля 2007, 13:12:37 Михаил
Цитировать А что насчет контента, вносимого тобой в "Н"? Как-то ты скромно умолчал... Какова для тебя его актуальность? Попытаюсь другими словами объяснить то, что уже пытался донести до тебя выше NothingAnother: Контент, вносимый в список "Н" актуален для меня ровно на столько, насколько я указал в критериях свежести! Т.е. обновление картинок на большинстве сайтах меня абсолютно не волнует! На этом я дополнительно экономлю немалый трафик, т.к. мне не надо загружать их обновленные версии! Если свежесть каких картинок для меня важна, то я просто занесу их в Белый список и пусть штатный If-Modified-Since каждый раз проверяет их свежесть! К слову, за 1,5 года использования HC у меня там всего 2 URL такого плана! Поэтому твои предположения: Цитировать Если б он располагал реальной информацией о том, что рисунки на некоем сайте обновляются чуть ли не раз в минуту, на другом - последний раз - год назад, а на третьем - еще с другой периодичностью, я думаю, он бы использовал эту информацию для соответствующей корректировки списка "Не обновлять". НЕ верны в корне! Список Н для того и создан, чтобы получать дополнительную (причем, немалую!) экономию на необновлении неактуальных для пользователя данных и чтобы пользователь мог сам указать, что и как часто он желает обновлять! Это значительно более выгодно, чем экономия мизерных байт и секунд на "лишних" запросах If-Modified-Since, которую предлагаешь ты! В общем, как и в предыдущих твоих темах, ты просто не желаешь слушать контраргументы своих оппонентов! Мой окончательный вывод из всего вышесказанного в этом топике: В лучшем случае предлагаемая тобой опция бесполезна, в худшем - вредна! P.S. На сим и мое участие в этом топике закончено! ;D Название: Re: Пытаться экономить путем предугадывания Отправлено: Михаил от 14 февраля 2007, 13:47:38 Про приведенный выше пример (http://handycache.ru/component/option,com_smf/Itemid,10/topic,205.msg1725/#msg1725) с нерегулярно обновляющимся сайтом типа Флэшгет (хоть человек и ушел, но вопрос-то повис). Существует категория пользователей (в часности, NothingAnother и DenZzz), для которых в таких случаях важно как можно быстрей стать обладателем обновленной информации. Для этого они по нескольку раз в день проверяют наличие обновления на сайтах, не обновляющихся годами (неся соответствующие расходы трафика/времени). Существует же категория (в часности, я), которые не ходят на такие сайты каждый день по нескольку раз, а вполне допускают потерпеть недельку-месяц между заходами. Оба подхода, на мой взгляд, равноправно имеют место быть. У каждого свой стиль серфинга и свои понятия, на чем нужно экономить. И если один не допускает мысли экономить на чем-то, то другой хочет на том же самом эффективно экономить (либо оба хотят экономить, но по-разному). Поэтому я предложил опциональный характер обсуждаемой функции. Для большей гибкости можно ввести дополнительную колонку в "Не обновлять", включающую/отключающую эту функцию для определенных типов данных.
DenZzz Цитировать В общем, как и в предыдущих твоих темах, ты просто не желаешь слушать контраргументы своих оппонентов! Я отношусь к этому твоему заявлению совершенно спокойно, т.к. оно уже звучало в топике про ненужность списка "Запись в кэш". Результат известен всему форуму.В лучшем случае предлагаемая тобой опция бесполезна, в худшем - вредна! Но все же интересно, что именно я не услышал? Вроде, старался отвечать на все... Цитировать Список Н для того и создан, чтобы получать дополнительную (причем, немалую!) экономию на необновлении неактуальных для пользователя данных НЕТ! На необновлении именно актуальных для пользователя данных. Все неактуальные сидят в "Черном списке" и может быть, "Только из кэша". Думаю, именно осознавая это скромно промолчал про этот список NothingAnother.Название: Re: Пытаться экономить путем предугадывания Отправлено: DenZzz от 14 февраля 2007, 14:30:09 Я отношусь к этому твоему заявлению совершенно спокойно, т.к. оно уже звучало в топике про ненужность списка "Запись в кэш". Результат известен всему форуму. У-гу, известен! mai62 сказал, что список "Запись в кэш" останется!!! ;D А то, что вы записали с Риком в ToDo в мое отсутствие, еще не означает, что это будет реализовано... ;) Дабы не оффтопить в этой теме, продолжение смотри здесь (http://handycache.ru/component/option,com_smf/Itemid,10/topic,86.msg1739/#msg1739)... Название: Re: Пытаться экономить путем предугадывания Отправлено: Rick от 14 февраля 2007, 16:15:08 У-гу, известен! mai62 сказал, что список "Запись в кэш" останется!!! ;D Не удивительно. Только зачем же злорадствовать то?Цитировать А то, что вы записали с Риком в ToDo в мое отсутствие, еще не означает, что это будет реализовано... ;) А жаль.По теме топика: Михаил, Лично мне твое предложение, сам принцип, кажется интересным. Дифференцированный подход для определения необходимости сделать запрос If-Modified-Since - мысль заманчивая. Однако рассмотрим пример: картинка-шапка на странице - элемент обновляющийся крайне редко. На малых сроках Т/15 будет небольшим и близким к возможным значениям критерия свежести в "Н", но чем старее картинка - тем больше период Т - т.е. если картинка не обновлялась год, то (365/15)*24 = ~576 часов - почти месяц - не великоват зазорчик? А если картинка все-таки за это время обновится (ну вот свершилось)? Имхо как минимум нужна верхняя планка для значения T - получается критерий свежести для критерия свежести. ;) Название: Re: Пытаться экономить путем предугадывания Отправлено: Death_Master от 16 февраля 2007, 05:26:28 предугадать невозможно, если не угробить 2-3 года на изучение действий одного конкрктного пользователя, на мой взгляд нанная модель не имеет практического применения(пока нет более точных алгоритмов презсказвния труднопрезсказуемых событий)
Ну и написал... хоть диссертацию пиши с такими-то фразами :) Название: Re: Пытаться экономить путем предугадывания Отправлено: Михаил от 16 февраля 2007, 18:09:15 Rick
Цитировать Однако рассмотрим пример: картинка-шапка на странице - элемент обновляющийся крайне редко. На малых сроках Т/15 будет небольшим и близким к возможным значениям критерия свежести в "Н", но чем старее картинка - тем больше период Т - т.е. если картинка не обновлялась год, то (365/15)*24 = ~576 часов - почти месяц - не великоват зазорчик? Согласен, верхняя планка Tmax опционально нужна. Это реально умерит расслабленность алгоритма на больших промежутках времени. У каждого это Tmax свое в соответствии с собственным видением. Оно - не "критерий свежести для критерия свежести". Получается абсолютный критерий свежести Tmax (все, что старше него, считать устаревшим) и относительный K (процент от промежутка времени, в течение которого файл не обновлялся). Вывод - для реализации этого подхода пользователь должен иметь возможность задавать для различных типов данных пару чисел: К (который я для примера брал равным 100/15~7%) и Tmax. Это можно реализовать, например, расширением списка "Не обновлять".А если картинка все-таки за это время обновится (ну вот свершилось)? Имхо как минимум нужна верхняя планка для значения T - получается критерий свежести для критерия свежести. Death_Master Цитировать предугадать невозможно, если не угробить 2-3 года на изучение действий одного конкрктного пользователя А кто говорит, что мы угадаем? Мы пытаемся угадать с высокой вероятностью, определяемой нами самими. Если же мы все-таки не угадываем, то мы заранее к этому готовы, т.к. прошедший промежуток времени для нас пренебрежимо мал. Точно в том же смысле мы угадываем сейчас, задавая критерий свежести: файл ведь может обновиться и до его истечения.
Powered by SMF 1.1.3 SMF © 2006, Simple Machines LLC
Joomla Bridge by JoomlaHacks.com |