HandyCache форум

На форуме руборда обсуждался вопрос расчета экономии. Предлагалось изменить сам расчет - не учитывать в нем то, что в принципе не поддается экономии: всевозможные zip, rar, 7z, avi, mp3, mpg и т.п. что по своему роду заведомо одноразовое, а так же то, что пользователь сам запретил сохранять в кэш, а значит, запретил экономию этого. Было и предложение считать в экономию то, что браузер взял из своего кэша, а от НС получил только подтверждение актуальности файла /304 Not Modified (HC)/.
Прозвучало радикальное предложение вообще убрать "процент" оставив только количество взятого из кэша (а это и есть экономия трафика). Процент относителен и, порой, сбивает с толку, а "Взято из кэш" величина абсолютная и совершенно правдивая.
Голосуем, высказываемся.
Голосовать могут только зарегистрированные и только один голос в руки. Но если в процессе обсуждения т.з. изменилась - можно переголосовать.

Rick, я как-то не понял - в твоей преамбуле три различных вопроса, а в голосовании только один... Ты будешь доделывать, или остальные ответы надо в виде "поста"?

NothingAnother, если я правильно тебя понял, ты имеешь в виду различные подварианты второго ответа: "Нужно, но считать его надо по-другому"? Думаю, пока преждевременно в голосовании этот вариант детализировать (разбивать на составляющие). Если окажется, что "процент" нужен (востребован/желателен), но нынешний его расчет не устраивает (т.е. 2-й ответ будет достаточно популярен) - тогда и будем определяться как лучше изменить расчет. Об этом можно (и нужно) здесь высказываться - на основании этих высказываний и будем определяться с подвариантами.

O'k, понятно... Маленькая ремарка - "Удалить Голос" находится непосредственно напротив пункта "Мне все-равно" - надо это как-то разнести, а то создаётся впечатление удаления не своего голоса, а голоса именно из этого пункта. И ещё - надо на главной странице как-нить обозначить, что проводится голосование - ведь, кроме прочитавших объяву на руборде, об этом никто и не знает...
По теме - несмотря на голосование за "Не нужно. Хватает..." - если перевесит пункт "...по-другому" то я против учёта, как экономии ответа "304", как несколько самоуправного, т.к. мы не можем наверняка знать, что браузер и без HC в этом случае не поступил бы так же (воспользовался собств. кэшем)

Признаюсь, относительно "304" у меня нет однозначного мнения как лучше - я сомневаюсь. С одной стороны, файл взят из кэша браузера, и это его (браузера) заслуга, что он его сохранил в свой кэш. С другой - HC пресек трату времени и трафика на запрос к удаленному серверу; во многих случаях браузер бы принялся качать тот же файл снова (зависит от случая и от конкретного браузера), хотя фактически файл идентичен тому, что у него в кэше (вот и явная экономия). Да и сама "заслуга" браузера (то, что он имеет файл в своем кэше), может свидетельствовать о неоптимальности настройки его кэша: одни и те же данные хранятся в двух кэшах. Но только _может_ а не свидетельствует всегда - это не относится к "текущим" файлам.

Почему это пресёк? Как же без запроса он узнал, что файл не обновился? Может, ты имел в виду контент, подпадающий под "не обновлять"? :-\В юридической практике есть постулат - "любые сомнения толкуются в пользу подозреваемого" :PВот уж никак не свидетельствует о "неоптимальности настройки" - огромное количество структур построено на двухуровневом буферировании - как хардварные (различные CPU и GPU), так и софтовые - графический вывод, стек TCP и т.д. В данном случае наличие данных в собств. кэше не означает их безусловной выдачи юзеру (или наоборот,- переприёму) - браузер и сам с успехом может с успехом использовать "304" (опять же толкование "может" см. во втором абзаце). И ещё - не совсем понял, что имеется в виду как "текущие файлы"?

Да, когда писал думал именно про "Н". Пошлите меня в FAQ (http://handycache.ru/component/option,com_simplefaq/task,display/Itemid,3/catid,1/#FAQ48)! :D

Разобраться бы еще кто подозреваемый. ;)

И в этой куче структур вроде не принято, получив данные из кэша первого уровня искать их (на всякий случай? ;)) еще и во втором. ::) Хранить в сопоставимых количествах одни и те же данные в кэшах обоих уровней сводит на нет всю двухуровневую затею.

Свежие файлы с последних страниц - то, с чем браузер управится быстрее не запрашивая их у НС. Только не спрашивай как определить "свежесть" - не знаю.  :-X

Ладно, относительно того, учитывать ли в расчете 304 Not Modified предоставим слово автору предложения - abz (если он пожелает высказаться).

Вот еще пища для размышлений (взял на руборде):
Ответ обычно сводится к "отключай НС перед загрузкой", "настраивай мимо НС" - и ради статистики отключается НС.

По самому расчету без учета трафика, который невозможно сэкономить писал unreal666:

Просто ремарка:
По моему мнению, оно не "заведомо одноразовое". Если пользователь один, то это так. Если же их несколько, то дело меняется. Если же эти пользователи объединены сходными целями и задачами серфинга в интернете, то оно становится ближе к "заведомо многоразовому".

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

М-да... Сложная будет тема, если победит вариант 2. Но интересная.

Пока вроде все идет к тому, чтобы оставить как есть. Хотя голосов еще мало для каких-то выводов.

Несколько раз уже на ru-board поднимали вопрос о статистике. Начиная с добавления дополнительных колонок в НС и заканчивая созданием индексных файлов для кеша и записью дополнительной инфо в потоки NTFS.
Imho, здесь снова вопрос столь противоречивый, что остается только одно - дождаться реализации плагиной поддержки. И там уж кому как надо будет видеть 200 вместо 304 пусть ставит и радуется процентам.

Проголосовал за 1 вариант, т.к. не вижу однозначно лучшего варианта подсчета экономии! ;)

Спорно! В большой сети, как уже заметил Михаил, можно экономить и на этом, причем существенно!

Пользователь мог и ошибиться с настройками правил "Белого списка" и "Запись в кэш", но он об этом не узнает, т.к. будет видеть большой процент экономии, который введет его в заблуждение относительно реального положения дел!

Как заметил NothingAnother, это зависит от конкретного браузера и настроек его кэша!
Например, Опера гораздо реже спрашивает у HC файлы, беря их из своего кэша, в отличие от IE, который постоянно стучится к HC! Следовательно, посчитать реальную экономию без отключения собственного кэша браузера (который в IE и не отключается, вовсе!) невозможно!
Кроме того, узнать размер этого "304" HC может только из своего дискового кэша (если он там есть), что замедлит работу и увеличит нагрузку на диск/систему! Не вижу смысла...

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

Кроме того, в подсчете реального процента экономии невозможно учесть заблокированную рекламу и прочих нежелательный контент!

В общем, подсчитать реальный процент экономии невозможно!

Конечно, цифры в Мониторе HC ориентировочные и верить им можно с упоминанием всех "если", но лучшей и более правдивой альтернативы я, к сожалению, не вижу!

Поэтому и проголосовал за 1 вариант! 8)

Как-то не логично. ;) Тогда следовало голосовать за 3-й.

Ну, почему же... Процент экономии в Мониторе меня сейчас вполне устраивает, т.к. я адекватно отношусь к его значению и понимаю, почему оно может расти/падать.

Например, до версии 0.98b1 средний отображаемый процент экономии у меня был 70-80% (браузер - Макстон).
С версии 0.98b1 средний отображаемый процент экономии как бы уменьшился до 50-60%...
Но я-то понимаю, что реальная экономия не изменилась, а отображаемый процент уменьшился из-за оптимизации работы HC (http://handycache.ru/component/option,com_smf/Itemid,10/topic,91.msg625/#msg625) с собственным кэшем браузера.

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

ИМХО, пусть процент останется как есть, т.к. бесспорно улучшить его не получится и не всем это нужно!
Меня, для целей сравнения экономии в динамике, устраивают и существующие значения... ;)

А индивидуальным подсчетом экономии пусть занимаются плагины и сторонние программы! Кстати, это легко можно было бы сделать и через анализ логов Монитора сторонней программой! Но пока, увы, не нашлось добровольца, написавшего такую программу... ;)

Ну да, за что боролись - на то и напоролись:
Т.е. после оптимизации показываемый процент стал еще меньше, а у нового пользователя больше поводов разочароваться и снести НС.

У новых пользователей с большим собственным кэшем браузера, который они боятся очистить, т.к. поставили HC на пробу, увеличение скорости загрузки страниц будет хорошо заметно "на глаз" и без всякого процента! ;)

Кроме того, оптимизация уменьшила нагрузку на диск, который, как известно, довольно медлителен!

Что касается уменьшения отображаемого процента экономии, то, например, пользователи Оперы практически не заметят разницы, т.к. их браузер и раньше брал из собственного кэша многие файлы без спроса у HC... ;)
А вот пользователи IE (Макстона и т.п.) по отображаемому проценту экономии теперь приблизились к пользователям Оперы! Не вижу в этом ничего плохого! :)

Все опытные пользователи HC понимают, что и как влияет на расчет экономии и понимают низкую степень достоверности "процента". А многие просто на него не обращают внимания.
Но это не относится к новичкам, для которых этот процент и есть показатель/ответ "а нужен ли мне?" только-что поставленный на пробу HC.
Считая процент себе в ущерб НС пилит сук на котором сидит. Кто-то произнес "маркетинг" - да, он самый. Но не обман и не очковтирательство - а процент, показывающий то, что реально сэкономлено из того, что вообще можно сэкономить.

Уже сейчас через НС может идти трафик никак не поддающийся кэшированию и экономии: https и ftp. Не за горами socks и portforwarding - через НС пойдет еще больше некэшируемого трафика. НС станет "более прокси", чем сейчас. А вопрос "процента" еще более обострится: когда через HC начнет качаться мыло, работать ftp-клиенты и т.д и т.п. - ни о каких 50% в экономии мечтать не придется. Экономия будет все той же, а процент упадет ниже плинтуса. А на этот самый процент все так же будут смотреть новички, и так же по этому же проценту будет оцениваться эффективность НС. Думаю, что неизбежно придется или менять расчет или убирать процент вовсе. Так чего дожидаться?

А с какой целью ты отслеживаешь динамику экономии? Зачем тебе эта "средняя температура по больнице", да еще в динамике?
Вчера я ходил по форумам - у меня высокий процент экономии. Сегодня также хожу по тем же самым форумам, но параллельно еще фильмец качнул с рапиды - экономии <1%. Ну и что можно увидеть из этой "динамики"? Ах, чтобы что-то увидеть мне нужно качать файлы мимо НС? А зачем я должен что-то переключать-менять, почему НС не может сам посчитать правильно без моих дополнительных телодвижений?

"На глаз" - плохой измерительный прибор. Как правило "глаз" покажет то, на что настроен пользователь: хочет он увидеть, что стало быстрее - увидит ускорение, а настроен скептически - увидит тормоза. А потом переведет взгляд на экономию и увидит мизерный процент - и все готово для вынесения "приговора".

Да это понятно. Вот только _кому_ это понятно? Тебе, мне, пользователям "со стажем"? А тем, кто впервые ставит НС это не то что не понятно - просто не ведомо. А ведомы им собственные ощущения (вроде стало лучше, а может только кажется?) и "процент". Хорошо, если пользователь понимает, что НС - по-определению полезная программа, и придет узнавать причину низкой экономии сюда. А если не понимает - просто снесет НС да и дело с концом. Жил же он себе без НС и горя не знал. Лучше поставить TrafficCompressor - вот там явная экономия и разрекламирован продукт и на каждом углу известен. "Процент" считает любо-дорого посмотреть: неподдерживаемый трафик (ZIP, MP3, EXE файлы, FTP, HTTPS, SMTP трафик и т.д.), передается напрямую, минуя TrafficCompressor: оно и правильно, и "процент" не портит. А мы тут рассуждаем "процент совершенно неадекватный, но мы же знаем, что ему верить нельзя - так что все хорошо, не видим ничего плохого". Мысли о тех, кто не знает, а просто принимает на веру показания "процента" не возникает.

Можно конечно расширить статистику и считать отдельно
1. HTTPS
2. FTP
3. Большие файлы (которые смогли определить :) )

То число в процентах, о котором идет речь, я никогда не называл экономией. Рядом с этим числом написано "Взято из кэша". Вот именно так его и следует понимать.
Глупо рассчитывать, что только-что поставленный HC, тут же начнет приносить пользу именно в виде взятых из кэша файлов - самих файлов пока просто нет в кэше. И тут нужно не идти на поводу у заблуждающегося потенциального пользователя, а разъяснять ему что к чему (и про резку рекламы, и про кэш браузера, и про автономную работу, и про историка и про то о чем я щас тут забыл написать). Если у него с нашей помощью будут открыты глаза на программу и на присходящее при ее участии, он сам решит нужен ли ему и для чего нужен НС.

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

Да, глупо. Поэтому пользователь, удаливший НС из-за того, что не увидел никакой экономии на первой же открытой странице - не наш пользователь. Совсем не наш. :)

Не согласен. Вопросы расчета экономии и факторов влияющих на "процент" освещены в FAQ'е и документации, но тем не менее вопрос "почему у меня низкая экономия" неумирающий - поднимается на форуме вновь и вновь регулярно. И будет подыматься, потому-что ответ на этот вопрос пользователю должна давать сама программа, а не форум/документация.

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

Значит надо натыкать пояснялок - посмотрел пользователь на процент, а ему бац, баллончик всплыл - "Маленький процент экономии? Узнайте что делать!" Как в новых виндах и офисах. Очень даже удобный и приятный метод.

Предложение из другой темы:


Сравнивать количество запросов к кэшу+заблокированных с теми, что ушли в Инет - звучит неплохо...

Тогда формула будет примерно такой:

ЭКОНОМИЯ=(ответы из кэша "200" + "304 Not Modified (HC)" + заблокированные HC "403, 430")/все запросы *100%

Можно также сделать смешанный подсчет экономии через весовые коэффициенты, например:

Суммарная экономия = 0.5*Экономия на трафике + 0.5*Экономия на запросах

Было бы здорово самому вписывать в настройках формулу расчета и формат вывода.
Меня бы больше устроила финальная величина в рублях а не в процентах.

Жуть :)
Хотя сегодня столкнулся с диким желанием чтобы процент в мониторе стал большим-пребольшим, желательно >50% потому что поставил его на сервер для 15 пользователей, а экономия всего 4% и 80% запросов изображают 304 Not Modified (HC) А остальные загружаются из интернета.
По-моему это лишнее. У меня стоит НС для кеширования + стоит 3proxy для разбиения по пользователям, ограничения скорости, доступа к почте и всяких портмаппингов. Вот в 3прокси пишутся логи которые обрабатывает wrspy, отчеты - просто прелесть, даже время кто сколько просидел в интернете считает :) Вот поднял тему анализа логов это прогой от НС. Думаю скоро будет, тогда и формулы задавать не надо.

Когда создавалось голосование я про себя думал, что проводить его или хотя бы до 40-ка голосов (из расчета по десять на вариант ответа) или месяц. 40 голосов есть, месяц истекает завтра вечером. Закрывать голосование и подводить итоги, или продолжить голосование и обсуждение?

Не понимаю смысла предложения. Ну увидим мы количество или процент запросов - и что? В чем ценность знания этой величины? Платят ведь пользователи не за количество запросов, а за количество "метров" или времени. И экономят тоже не запросы.

Эх. Вопросы Вилли заставили читать про TrafficCompressor - читаю и сердце кровью обливается:
Почему же в HandyCashe не расчет экономии, а какое-то самобичевание? ::)

По-моему DenZzz просто высмеивает эту идею.
Просто наша программа - для думающих пользователей, а Traffic Compressor для оранусов (©Пелевин). Вот и все разница.
Но! Я передумал :) Давайте показывать большой и толстый процент, потому что сегодня такой случай - у всех пользователей потихоньку капает траффик, экономия около 25% (кеш только набирается, да и полные кеши у браузеров). И тут один пользователь выкачивает по FTP 32мб - все процент упал до 4%... Причем не закешировать этот фтп-траффик, ни как иначе использовать низя + icq через прокси тоже "no-cache no-economy".
Можно оставить текущий процент в качестве процента взятого из кеша, НО добавить ту самую экономию БОЛЬШИМИ БУКВАМИ и т.д. логику расчета давайте обсудим.

Это попытка оценить экономию на том, что оценить невозможно ни "метрами", ни временем, ни деньгами - это реальная экономия на заблокированных запросах "403" и "430" (срабатывание "Черного списка") , "404" (срабатывание списка "Только из кэша"), "304" (когда НС велит браузеру брать файл из его кэша) и т.д.

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


А почему "самобичевание" должно быть заменено на "самолюбование" а-ля TrafficCompressor?!

TC поступает весьма хитро - он сознательно игнорирует в статистике и без того уже сжатый контент. Например, если пользователь ходит в основном по сайтам с GZIP или много качает музыку, фильмы, архивы, то у него TC в основном бездействует! А как TC тогда сможет оправдать свою необходимость - да просто исключит из подсчета уже сжатый трафик и тем самым увеличит % экономии! Отличный маркетинговый ход для затуманивая мозгов неопытных пользователей!

Вернемся к HC - точно посчитать экономию в "метрах"/минутах мы не в состоянии по причинам, озвученным мной выше! Следовательно, % экономии от этого занижен - все это понимают! Но зато мы можем рядом хитрых уловок искусственно "компенсировать" % экономии, исключив из подсчета якобы "лишний" трафик!
Это не совсем честно и правильно, но вполне обоснованно с т.з. маркетинга и популяризации программы...

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


Какой смысл закрывать сейчас голосование? Мы что до чего-то договорились? Что-то решили? Голосование пока говорит только об одном - голоса разделились практически поровну между теми, кого все устраивает, и теми, кто хочет что-то изменить! А что именно надо менять - пока совсем не очевидно...

люди, а что значат 3 цифры в статистике? Первая, как я понимаю, общий трафик, вторая, то что взято из кеша. А третья? ???

Juve_83

Не совсем! Правильно так:
Взято из Интернета / Взято из Кэша (%) / Отправлено

Спасибо

Прилагаю файл с анализом запросов и размерами (по реальным данным 3 пользователя, разные браузеры, 12тыс запросов). Можешь рассчитать экономию как ты предлагаешь?

cepera_ang

О.К. Вечером посчитаю, результат выложу...

cepera_ang

Вот посчитал по твоим данным (см. приложение):

• Экономия на запросах (по моему методу расчета):         61,4%
  
• Экономия на трафике (существующий метод расчета):   17,9%
  

Как говорится, результат налицо! :)

Что ж красота ) Теперь применим метод
И получится средневзвешенная экономия = 38,95%. Неплохо, конечно отключив полностью кеш браузера (и в памяти и на диске) можно получить и 80%.
Я тут еще подумал, моя выборка может быть весьма непрезентабельной - большую часть рекламы вырезает proxomitron это уменьшает процент экономии по запросам (становится меньше 430 блокед бай НС), proxomitron же отдает уже распакованные странички, что уменьшает процент экономии по трафику + кеши браузеров очищаются при закрытии, что никак не влияет на экономию по запросам, но увеличивает экономию по трафику (НС чаще отдает файлы из кеша вместо 304). + у меня все сайты, кроме форумов обновляются только принудительно по хоткею.
Думаю стоит проанализировать еще данных для получения хорошей статистики. Через недельку накопится статистика на работе (там абсолютно среднестатистическое использование НС новым пользователем) интересно будет полазить.
Подумалось тут еще - вместо коэффициентов 0.5 и т.д. попробовать считать так:
Вычислить средний_размер_запроса = размер_кеша/кол-во_файлов - константа в программе, на основе широкой выборки данных (повычислять у всех пользователей форума и усреднить)
И считать: Процент = (Взято_из_кеша_байт + Кол-во_сэкономленных_запросов*средний_размер_запроса)/(Взято_из_кеша_байт + Взято_из_интернета - траффик_не_подлежащий_подсчету)*100%

Посчитал по все тем же данным - получил весьма интересные результаты. Рекомендую посмотреть вложение. Кажется это то, что нужно.

А может не стоит вычислять "среднюю температуру по больнице"? :)
Средний размер запроса у всех будет разный, т.к. он зависит от "стиля" серфинга и интересов! Поэтому возможны существенные различия у разных пользователей! У некоторых экономия, рассчитанная по твоей формуле, даже превысит 100%!

Например, у меня средний размер файла в кэше получился равен 7968 байт, что в 3 раза меньше твоего. А если бы я хранил в кэше музыку, фильмы и архивы, то это значение возросло бы в разы!

Более точный результат может дать автоматический расчет среднего размера запроса у каждого пользователя на его копии HC - можно делить трафик, полученный из Инета с ответом "200 ОК [gzip]", на количество таких ответов. По твоим цифрам получается: 28444 байт/запрос и 67% экономии.

Но как ты заметил, при таком расчете экономия может легко превысить 100%, что по смыслу абсурдно и вызовет недоверие у пользователя! Да и хлопотно это - постоянно считать средний размер запроса в реальном времени...

Это, собственно и предлагалось. Большими буквами правда не обязательно. :)

Хм... Ставлю себя на место пользователя читающего в доке/факе объяснение расчета экономии и не понимаю: что мне дает экономия количества запросов? Возвращаюсь на свое место и не знаю, что объяснять такому пользователю, когда он придет на форум с вопросом зачем ему может быть нужен такой "процент".

Пожалуй согласен, но не вижу способа как это можно достоверно посчитать.

О самолюбовании и тем паче каком-то очковтирательстве и речи нет - поскольку вариант показывать _только_ трафик поддающийся экономии даже не рассматривается.

1. Что-то я смотрю последние предложения из "единственно честного способа" превратились в "можно вычислить любой понравившийся процент и подогнать константу размера запроса".  :-\
2. Ныне существующая величина "Взято из кэша" самая что ни на есть честная - дык может, все-таки третий вариант? ;)

Мне навскидку (сырое) видится что-то примерно такое:
Общий трафик (ОТ) - все, что прошло через HandyCache (MB).
Трафик не поддающийся экономии (ТНЭ) - все, что было передано клиенту без записи в кэш (MB).
Трафик поддающийся экономии (ТПЭ) = ОТ - ТНЭ (MB).

Взято из кэша (ВК) - так и есть, взятое из кэша (MB). (Ответы "200 ... (НС)")
Необновляемые файлы (НФ) - файлы "304 Not Modified (HC)" - т.е. размер файлов которые есть в кэше НС и совпадают с файлами из кэша браузера, но ответ 304 дан безоговорочно - без запроса к серверу (MB). (А если запрос к серверу был, то это входит в ВК)
Сэкономленный трафик (СЭ) = ВК + НФ

Экономия = ( СЭ / (ТПЭ + ВК) ) * 100%

Пример:
Общий трафик 250M, из них 100М файлы не записанные в кэш, взято из кэша 50М, необновлено (304 Not Modified (HC)) 10М.
ТПЭ = 250 - 100 = 150М; СЭ = 50 + 10 = 60М; Экономия = (60/(150 + 50))*100% = 30%
При нынешнем расчете экономия считается как (50/240)*100% = 20,8%

ЗЫ: Я не знаю точно, но вроде бы сейчас 304 Not Modified (HC) не считаются никуда: ни в "Взято из кэш", ни в "Взято из интернет" - поэтому в расчете "по-нынешнему" 240 а не 250

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

Допустим, экономия получилась 50% - это значит, что половину всех запросов HC сформировал сам, не тратя время на обращение в Инет! В грубом приближении (без учета времени обработки запросов самим HC, т.к. оно сравнительно мало) он сэкономил половину времени, требуемого на полную загрузку страниц!
Чем медленнее канал, тем больше минут будет сэкономлено! А это вполне реальная величина, которую каждый сможет оценить сам!


Не нравится мне этот пункт! Причин несколько:
1. Этих файлов может и не быть в кэше вовсе!
2. Нам придется проверять наличие всех этих файлов в кэше.
3. Если файл есть в кэше, то придется узнавать его размер и вести отдельный подсчет.

п.1 вносит неточность в расчет, пп. 2 и 3 увеличивают нагрузку на диск, чего мы и пытались избежать, вводя обработку "304".

Кроме того, по-прежнему не делается попытка учесть (хотя бы гипотетически!) экономию от работы "Черного списка" и "Только из кэша", а это вносит существенную погрешность  в расчет итогового процента экономии!

Предложение:
 добавить статистику по запросам (всего, из кеша, not modified и т.д.)
хотя по моему мнению это все от лукавого, проще это все в анализаторе логв сделать...

Да, невозможно. Но и "относительную оценку реальной экономии" на запросах не посчитаешь. Что файл 1К, что 1М, что 10М (и т.д.) - разный расход трафика и разное время, а запрос у всех один.

Рассмотрим (так же грубо) житейскую ситуацию: зашел на рапиду (не в первый раз) и скачал файл весом 100М. Элементы оформления взялись из кэша, код-картинка и страница загрузились из инета, ну и сам файл тоже разумееется. И что нам покажет количество запросов? Да то, что 99% (картинки оформления) взяты из кэша - значит ура, сэкономили! А на самом деле 99% реальных затрат времени и трафика ушли на тот 1% несэкономленных запросов.


Да, его додумать надо.

Нет файла - нет размера - нечего считать.

Сошлюсь (http://forum.ru-board.com/topic.cgi?forum=5&topic=21354&start=1580#20) на мнение mai62 именно по этому вопросу:

Есть предложения как учесть размер несуществующего в кэше файла?

:-X

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

Какой смысл портить статистику тем, что в принципе нельзя сэкономить?
99% будет правдивее. Можно назвать это эффективностью.
Хорошая идея, кстати.
Процент уберем из второй строчки. Внизу добавим еще две строчки в мониторе.
Эффективность в процентах
Экономия в рублях или минутах

А на график желательно нанести шкалу скорости. А то нифига не понятно что за кривая рисуется.

А может назвать тем, чем оно на самом деле является: Количество запросов, обработанных без обращения в сеть?

Я предложил назвать Эффективностью вовсе не количество запросов. См. предпоследний пост на предыдущей странице.

Мы это уже начали обсуждать на предыдущей странице (http://handycache.ru/component/option,com_smf/Itemid,10/topic,158.msg2151/#msg2151)!


Что так? Запретная тема или не согласен с "лишней нагрузкой на диск"? ;)
Если и делать учет "304" в кэше, то только опционально, чтобы можно было отключить эти лишние обращения к диску, т.к. цифра % экономии лично для меня менее важна, чем использование системных ресурсов!


Я бы даже сказал: "Минимальная эффективность", т.к. здесь не учитываются блокировки списками "Ч" и "Т", которые эту самую "Эффективность" увеличивают!
Вопрос только: как их учесть, чтобы получить "Реальную эффективность"?


Экономию времени вообще посчитать невозможно, а тарифы за трафик у всех разные или "безлимит" с абон.платой!


Это про мой метод расчета? Я не против! Но Rick придумывал название для своего метода (http://handycache.ru/component/option,com_smf/Itemid,10/topic,158.msg2413/#msg2413)... а мой ему вообще не нравится... :)

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

Если ответ 304 Mot modified (НС) то как файла может не оказаться в кеше? Ведь этот ответ дается после поиска файла в кеше и проверки его даты?

Нет. Этот ответ может выдаваться и без наличия файла в кэше, если:
- сработало правило в списке "Только из кэша";
- сработало правило без критерия свежести в списке "Не обновлять".

Т.е. наличие файла в кэше при формировании ответа "304" обязательно только для проверки правил с критерием свежести в списке "Не обновлять".

Слишком грубую! Думаю, не стоит рассказывать, что максимальная скорость канала отличается от реальной скорости загрузки с разных серверов в каждый конкретный момент времени! И зависит она и от текущей загрузки сервера, и от загрузки канала, и от возможностей провайдера и т.д.
Ситуация та же, что и с "константой размера запроса" - достоверное значение не получится!

Будет 404 (НС)

Будет 200 ... (HC)

А если файл есть в кеше браузера, но отсутствует в кеше НС и браузер посылает запрос с if-modified-since?

Во-первых, не "200 ... (HC)", а "200 ОК", т.е. грузим из Инета, когда в кэше файла нет!

А во-вторых, не "будет", а так "было" до версии 0.98b1!

Сейчас, если запрос пришел от браузера с заголовком "If-Modified-Since", то будет "304" в описанных мной выше случаях!

Значит пора править FAQ? ;)
Только проверь прежде чем править - например у меня так и было и есть.

Я проверял без I-M-S.

Сорри за оффтопик...


Какой конкретно вопрос править? В описании ответов сервера (http://handycache.ru/component/option,com_simplefaq/task,display/Itemid,3/catid,1/#FAQ48) это давно есть!


Я "родил" эту логику обработки HC запросов с "If-Modified-Since", я ее и тестировал! Поэтому мне ли не знать, как она работает! ;)

DenZzz
Да, это я про попытку предъявить пользователю оценку пользы за счет самостоятельной обработки запросов без их отправки серверу.
Мне кажется лучше пусть будет два параметра оценки эффективности: по трафику и по запросам. Алгоритмы их вычисления должны быть объективными, давайте считать то, что мы можем посчитать.
Подтверждаю.

Я в этот смайлик вкладывал слова "воздержусь от комментария".

Любая операция требует каких-то ресурсов компа, но не всяких операций нужно пугаться и запугивать этим других. ;) Например каждый RClick по строкам в Мониторе влечет за собой обращение к диску - тоже сделать опционально?
Реальных затрат на проверку существования файла и чтение его атрибутов (размера) - мизер.

А тебе самому все еще нравится? :o

Не очень понятен резон таких родов. Но как бы то ни было, ответы-ответами, а подсчеты-подсчетами. Нет файла в кэше - он не считается - никаких проблем.

Утром пару раз смотрел в FAQ и удивлялся: как ты умудряешься в FAQ'е писать одно, а здесь противоположное. После утверждения что "все уже есть" еще раз перечитал: да, зная что именно я ищу - я это нашел. Править нужно описание 200-х, 404-го и разжевать 304-й.

А никак их не учесть. Не вижу никакого способа. "Самый честный" подсчет запросов на деле не более чем вилами по воде. Можно, например, каждый заблокированный запрос считать по 2К но это тоже гадание на кофейной гуще. Поэтому, может и не стоит пытаться притянуть за уши то, что посчитать нельзя?

RClick я жму, когда мне нужно это контекстное меню, а "304" ты предлагаешь учитывать всегда, хотя оно мне совсем не надо - что так неправильно считает, что так!


Когда диск интенсивно загружен другими операциями (антивирусной проверкой, поиском файлов и т.п.), то этот мизер превращается в вполне реальные секунды!


А-га. И mai62 нравится... :)


Пример "противоположного" можно?


Ну, разжевал бы сам, как тебе понятнее...


А заменять один неправильный расчет "экономии" на другой неправильный лучше?

Повторяю: это никакие не траты ресурсов - это мизер, пыль.

Повторяю: не нужно пугаться и запугивать несуществующими проблемами других. ;)

Да, нужно в FAT/MFT найти инфу о файле - поскольку сам файл на диске не ищется и не читается все очень быстро.
При включенной опции "Добавлять I-M-S при наличии файла в кэше" это делается для каждого запроса в сеть - и ничего, никто караул не кричит.

Во-первых, я бы предпочел это услышать от самого mai62 или увидеть его цитату. Во-вторых, я сильно удивлен. Что в предложении считать количество запросов может нравиться? Недаром это предложение сначала было воспринято невсерьез, а как сарказм - это же мягко говоря чушь, грубо говоря бессмысленный расчет. :) С тем же успехом можно считать отношение времени работы НС к времени простоя: расчет точный? - абсолютно, смысл имеет? - ни малейшего, этот расчет никому не нужен.

Из двух зол нужно выбирать меньшее. Если не находится варианта вообще без "зла".

Кроме того, что тебе не нравится подсчет размера необновляемых файлов есть какие-то рациональные мысли? Например, как тебе кажется правильным их (НФ) считать?

Повторяю: во многих случаях можно обойтись БЕЗ всякого обращения к FAT/MFT, которые физически хранятся все на том же медленном диске! Как любит говорить один хорошо нам известный человек, озабоченный вопросами оптимизации: "Курочка по зернышку клюет!"
А делать лишний запрос к FAT/MFT только ради того, чтобы увидеть "красивую" цифру экономии в Мониторе, не имеющую отношение к реальной экономии - это как раз тот случай, когда цель НЕ оправдывает средства!
 

Вот тут цель оправдывает средства, т.к. позволяет нам сэкономить вполне реальные мегабайты, а не "пустить пыль в глаза" пользователю красивой цифрой...


Каждый замечает только то, что он желает видеть! Возможно, и я не совсем точно понял реплику mai62, но его фраза насчет расчета эффективности по запросам отнюдь не намекала на то, что это, как ты говоришь "мягко говоря чушь, грубо говоря бессмысленный расчет":


Мне кажется правильным их вообще НЕ считать!

С чего ты взял, что размер HФ должен прибавляться в полном размере к сэкономленному HC трафику? Если бы не было HC, то браузер также послал бы "I-M-S" серверу, весьма вероятно получил бы "304" от сервера и взял файл из своего кэша! Реальные затраты трафика 1-2 кб на запрос! Почему в таких случаях HC должен брать полный размер этого файла из своего кэша! Это элементарное накручивание процента экономии! Чем это правильнее, чем считать запросы?!

Кроме того, правильные браузеры с правильным кэшем намного чаще берут файлы из своего кэша без обращения к HC, поэтому "304" там можно увидеть гораздо реже, чем в глупом IE. Поэтому у пользователей IE расчетный процент экономии ранее был якобы выше, чем в Опере, хотя на самом деле счетчик просто "накручивался"! Теперь это неравенство сглажено - Опера и IE при равном серфинге показывают близкие проценты взятого из кэша HC ("экономии"), что есть справедливо и правильно!

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

"Красивая цифра" - это не цель. Это скорее побочный результат отвечающий интересам HandyCache. Я считаю, что "процента" или не должно быть в Мониторе вообще (нет процента - нет проблемы), или он должен показывать реальный процент сэкономленного из того, что поддается экономии. При этом "чистый" процент взято из кэша/общий трафик так же обязательно нужен.
Я был бы рад, если бы ты перешел от полемики ЧТО считать к предложениям КАК считать процент сэкономленного из того, что поддается экономии - а не изобретал именно "пыль в глаза".

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

Ничуть не менее вероятно, что браузер стал бы тянуть файл из инета.

Считать запросы - полезная функция для статистики. Squid, например, считает и количество запросов в час, и по пользователям, и вес запросов и т.д. Но это статистические данные - никто не расценивает их как показатель _полезности_ прокси. Считать экономию запросами - это как и воду, и гвозди, и опилки мерять ведрами: единица измерения не та.

Да, правильный браузер просто берет файл из своего кэша, а глупый IE лезет в инет. И без НС так и получается, что IE жрет трафика больше чем та же Опера - и никаких накруток: жисть такой.

Пока нет. Вот если появятся индексы...
Хотя в нашем конкретном случае узнавание размера файла с целью накручивания "экономии" - это, мягко говоря, лукавство!


Это экономия на запросе размером 1-2 кб и она никак не равняется размеру этого файла в кэше HC !


После моих "родов" снизилось использование ресурсов системы (диска, памяти и процессора), т.к. HC теперь не надо повторно читать файлы из кэша и передавать их снова и снова браузеру, когда они у того и так уже есть, и при этом искусственно накручивая процент "экономии"!
И за 2 месяца с появления этой фичи я ни разу не слышал от пользователей о реальных проблемах такого подхода, кроме реплик типа: "Хочу вернуть мой большой % экономии! Я знаю, что он считался неправильно и показывал неизвестно что, но он мне душу грел!"


Отвечу твоими словами: "это как и воду, и гвозди, и опилки мерять ведрами" - "это же мягко говоря чушь, грубо говоря бессмысленный расчет"!
Приведу слова mai62: "давайте считать то, что мы можем посчитать".
И от себя добавлю: не нужно придумывать взятые с потолка компенсации за то, что точно посчитать мы не в состоянии!


Чуть! Причем, намного "чуть"!

Ответ "304" HC сам формирует только при срабатывании списка "Т" или "Н". В этих списках почти у всех нас содержатся картинки, скрипты и стили, которые в подавляющем своем большинстве статичны или обновляются крайне редко! Поэтому в большинстве таких запросов с "I-M-S" к серверу браузер получит "304" и не будет качать файл снова!

Из своих наблюдений и анализа логов могу сказать, что примерно в 90% случаев, когда HC у меня формирует "304", сервер бы ответил точно также! Еще до того, как появился HC, я много раз на IE (Макстоне) наблюдал такую ситуацию! Закэшированные картинки даже глупый ослик в большинстве случаев брал из своего кэша, хотя запросы в Инет он упорно делал, но серверы постоянно посылали его на "304"... :)


О.К. Тогда еще немного покритикую твою формулу (http://handycache.ru/component/option,com_smf/Itemid,10/topic,158.msg2413/#msg2413)...

Экономия = ( СЭ / (ТПЭ + ВК) ) * 100%

Житейская ситуация - неопытный юзер, попользовавшись дефолтными правилами, решил заменить их на свои или добавить исключения в "Белый список", но сделал он это неправильно и далеко не все учел, что надо бы кэшировать! А может он, вообще, по незнанию поотключал ненужные на его взгляд правила!
Тогда ТПЭ будет маленьким, % экономии большим, вселяя ложное спокойствие и ощущение правильности сотворенных действий в ум начинающего пользователя!
Разочарование наступит, когда он увидит свой счет за Интернет! ;)


И еще про твою формулу... Ты ее зачем-то свернул, я ее разверну:

Экономия = ( (ВК + НФ) / (ОТ - ТНЭ + ВК) ) * 100%

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

Теперь смотрим на твою развернутую формулу - ОТ станет равен ТНЭ, сокращаем равные величины:

Экономия = ( (ВК + НФ) / ВК ) * 100%

Уга, товагищи! Революционный прорыв технологии - экономия превысила 100% !

Теперь HC не только экономит наш трафик, но и доплачивает нам за серфинг! Ура-а-а!  :)

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

С чего бы это ты напрочь "забыл" про случаи, когда пресечена именно загрузка файла и отдан файл из кэша?

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

И хорошо, что не читает и не впаривает браузеру тот же самый файл. Совершенно правильно: это было никчемной операцией. И "роды" очень даже правильные. Только я не понимаю, каким это боком к вычислению процента? Почему у тебя прочитать файл и передать его браузеру = прочитать атрибуты файла. Ничто не мешает НС, при ответе 304, проверить наличие файла в кэше, и если он есть - прочесть его атрибуты. Тем более, во многих случаях он именно так и делает.

Гы... У тебя семь пятниц на неделе. То ты не доволен, почему не учтена экономия от блокированных запросов, то вдруг прозреваешь, что посчитать это невозможно и разворачиваешь свое возмущение на 180 градусов. То ты ссылаешься на слова mai62, то напрочь их не замечаешь.
Какой-то предвзятый у тебя подход - не пора ли менять? Лично я, например, за то, чтобы вообще не показывать никакой процент в главном окне: процентам место в статитистике. А точнее, даже не в ней, в результатах ее обработки. Но тем не менее, на данный момент вопрос стоит именно так: как считать процент в главном окне - поэтому пожалуйста приложи по возможности усилия к поиску ответа именно на этот вопрос, а не как доказать необходимость ничего не менять.

А не надо критиковать - формула сырая, о чем я сразу и предупредил. Я извиняюсь, что сразу не сказал : "Дорогие друзья, не надо искать повод подкузьмить, формула сырая - в автономке, например, покажет >100%, формула требует обдумывания - присоединяйтесь." Я сказал просто: она сырая. Ну дык коли по моей вине ты увлекся критикой - может теперь увлечешься конструктивом?

Да нет, все я прекрасно понимаю! Понятно, что один из способов убедить новичка пользоваться HC - это показать ему очень большой процент его выгоды (экономии)!
Мне только не нравится способ, которым предлагается это сделать! Фактически, то что мы не можем точно посчитать, ты предлагаешь просто завысить...
С таким же успехом я могу предложить: а давай с помощью генератора случайных чисел сделаем, чтобы процент менялся в диапазоне 80-100% - новые пользователи будут просто "счастливы"!


Не забыл. Я просто акцентирую внимание на том факте, что экономия, о которой мы можем гарантировано говорить в случае "304" - это всего 1-2 кб на запрос! Больше? Да, возможно, но по моим наблюдениям всего в 10% запросов! Поэтому примерно в 90% случаев считать экономией размеры эти файлов в кэше - это сознательное завышение экономии, т.е. обыкновенное "приписывание"!
А раз мы не можем точно посчитать экономию на "304", то либо не стоит и пытаться, либо считать по минимуму:  НФ = 1,5кб * Количество ответов "304" - но, как ты понимаешь, в итоге НФ получится мизерным!


Да, ты прав! Скромность - мое второе главное качество, после честности... :)
Но сейчас разговор не обо мне...


Ну, слава Богу, наконец-то "гадкий утенок" превратился в "белого лебедя"!


Ну, почему же! Я всегда, как и mai62, говорил, что надо считать то, что мы можем посчитать точно: будь то трафик из кэша или количество запросов без обращения в сеть, а заниматься умозрительными приписываниями и компенсациями - это не я прелагал! Ты меня с кем-то путаешь! ;) Я всегда пытался предостеречь от этого других...


Если тебя это утешит, то и я уже после наших длительных дебатов начинаю склоняться к этой мысли!
Не понятно только, почему % в мониторе у некоторых пользователей, по твоим словам, ассоциируется с "экономией", хотя это всего лишь процент взятого из кэша!
А реальная экономия гораздо больше, но посчитать ее точно мы не можем! Мы можем только попытаться приблизительно ее оценить по нескольким количественным параметрам: трафику из кэша, количеству сформированных HC ответов и т.д.


Очень сырая - больше 100% она также покажет, если, например, зайти на сайт фотогалереи с большими фотками и пару раз нажать "Обновить"...


Конструктив - это дать пользователю точные показатели, а эффективность HC (реальную экономию) пусть он уже оценивает сам: по трафику, по уменьшению количества запросов, по анализу логов в сторонних программах, по счетам от провайдера, по субъективному ускорению загрузки страниц и т.д. и т.п. ...

Летело мочало... Мы можем совершенно точно посчитать размер файла в кэше при запросе которого был дан ответ 304

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

Не утешит. Поскольку "дебаты" больше похожи на вставление "шпилек" чем на попытку нахождения решения.

Ай-яй-яй... "По твоим словам..." Щас договоришься, до того, что и вся проблема высосана мной из моего же пальца. Успешно "забыв" про все вопросы и топики про "экономию" на/в которых сам же и отвечал на эти вопросы. lol

Я не называю предлагаемый "процент" Экономией. Я называю его Эффективностью - Эффективностью кэширования, если угодно: т.е. отношение взятого из кэша к помещенному в кэш (ТНЭ - трафику поддающегося экономии). По сути этот процент действительно может быть >100% если мы больше берем из кэша чем помещаем в него - пользуемся плодами предыдущих "трудов".

Нынешний процент всегда маячит перед глазами пользователя и именно его он воспринимает как показатель экономии. Во всяком случае неискушенный пользователь/пользователь недавно начавший свое знакомство с НС. Чтобы этого не было нужно убрать процент вовсе - чтобы никого не сбивал с толку. Или (с т.з. популяризации это имхо более правильно) показать другой процент. Другой - не значит взятый с потолка, а рассчитанный исходя из других исходных данных, показывающий другую величину.
Например, вместо Взято из кэша: 10М/3% показывать Статистика: 10М / 40% / 60% - где 10М - абсолютная величина взятого из кэша, 40% - эффективность кэширования, 60% - КПД блокирования запросов. При таком раскладе, скореее у пользователя возникнет вопрос какой процент что означет (и он будет узнавать это из доков), чем одназначная трактовка что единственный показываемый процент - и есть экономия. В идеале хорошо бы, чтобы пользователь сам мог настроить какие именно показатели (из имеющихся вариантов) показывать в этой строке в главном окне НС.

Я не гадаю, а опираюсь на свою статистику: я сравнил количество срабатываний разных правил в списках "Не обновлять" и "Только из кэша" и пришел к заключению, что в 90% случаев - это правила для картинок!
99% всех картинок - статичны, следовательно, вероятность, что они никогда не обновятся на сервере, близка к 100%!

Исходя из этого, я утверждаю, что почти в 90% случаев формирования HC ответа "304" браузер наверняка получил бы точно такой же ответ с сервера!
Гадание? Нет! Статистика, наблюдения и опыт!


Ну, не может экономия, эффективность, КПД и т.п. быть больше 100%! Это противоречит здравому смыслу! 100% - это верхний предел, выше уже некуда!
100% - это КПД "вечного двигателя", который, как утверждают физики, создать невозможно!


Учитывая, что правильно посчитать НФ мы не в состоянии, предлагаю хотя бы убрать эту величину из твоей формулы - без нее твоя формула никогда не даст больше 100%! Получится, так:

Эффективность кэширования = ( ВК / (ОТ - ТНЭ + ВК) ) * 100%

Но придется делать допущения, что пользователь знает, что творит (какие правила он включил в списке "Запись в кэш", какие исключения добавил в "Белый список" и т.п.), т.к. высокий процент вовсе не будет означать, что он получает максимально возможную экономию!


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

В твоих условиях может быть так, в иных - этак. Следовательно это гадание.

Да запросто! К примеру, ты допускаешь, что в жизни один вложенный рубль может принести 5 рублей? А это 400% чистой прибыли.
Вернувшись к нашей теме: в зависисимости от того как считать мы можем получить эффективность >100% - но это всего лишь будет означать, что мы ничего не записываем в кэш - мы пользуемся записанным ранее (а-ля автономка). Соответственно 1) в прежние дни мы имели много меньший процент, а сейчас получили "выхлоп" от сделанных "вложений" и 2) Все зависит от периода времени по которому делается расчет.

Предложение считать экономию на "304" по размеру файлов в кэше - это еще большее гадание!


Но это уже не "экономия" и не "КПД"! Это прибыль, рентабельность и т.п. - другая категория!
HC не приносит прибыли его пользователю! Он только экономит его собственные деньги и время, а не преумножает их!


Ну, например, пришел  к тебе пользователь с 150% экономии и говорит: "100% экономии - это когда весь мой трафик взят из кэша. А еще 50% - это что?"
Как ответишь?

Хм... Ну посчитай КПД рубля, который принес 5 рублей (минус сам рубль вложений = 4 рубля). Что получилось?

Ну да, и что?

Не может придти пользователь со 150% экономии - это нонсенс. А если придет пользователь вопрошающий почему у него Эффективность кэширования > 100% ответ очевиден: значит он больше читает из кэша, чем записывает в него.

Уж точно не КПД! Вспомни физику или механику, откуда и пошел этот термин (http://slovari.yandex.ru/art.xml?art=bse/00038/29600.htm&encpage=bse) - КПД всегда меньше 100%!
То, что ты считаешь, называется в экономике "чистой прибылью" и "рентабельностью" - это к HC не применимо!


В нашем контексте "экономия" и "эффективность кэширования" - это одно и тоже! Поэтому эффективность кэширования и не может превышать 100%!

Назови хоть одного конкурента HC, который утверждает, что эффективность его программы может превышать 100%?
Над нами просто буду все смеяться!

Тебя несет по инерции - остановись, подумай.
Почитай свою же ссылку, где расписано в каких случаях кпд > 100%.

У нас как бы тоже не ДВС - так-что вполне применимо.

Тебя наверное сбивает с толку термин Экономия. Ведь действительно, чтобы сэкономить что-то >100% нужно не просто заполучить это "что-то" даром, но нужно еще чтобы и доплатили. ;D Но дело в том, что сейчас речь не про Экономию.
Представь: вчера ты записал в кэш 100М, из которых прочитал из кэша 20М , а сегодня, ты записал в кэш 50М, а прочитал из кэша 100М (читал, в т.ч., записанное вчера). И получается, что общий КПД за два дня 120/150=80%, за первый день 20%, а за второй 200%.
Представь, другую обыденную ситуацию: ты записал файл в кэш и ни разу не прочитал его - эффективность хранения этого файла равна нулю. Теперь представь, что ты таки однажды прочитал этот файл - его КПД=1 (тут или 0, или 1 - файл или был востребован или нет), а если один и тот же файл ты прочитал из кэша 10 раз то эффективность его хранения =10 (1000%). А ты говоришь, эффективность не может быть > 100% ;D - да запросто! Смотря как считать. ;)

С какого перепугу?

Эффективность программы <> Эффективность кэширования.

Там русским по белому сказано: "кпд всегда меньше единицы"!
Больше или равно 1 - это "вечный двигатель", который еще не изобрели! HC будет первым! :)


Ну, считаешь ты даже по твоей формуле неверно! ;D

За первый день: ВК=20, ТПЭ=100, КПД = 20/(100+20) = 16,6%
За второй день: ВК=100, ТПЭ=50, КПД = 100/(50+100) = 66,6%
КПД за два дня = (20+100)/(100+50+20+100) = 44,4%

Или ты все еще считаешь, что весь ВК (в т.ч. вчерашний!) уместился в собственном кэше браузера (который мы рекомендуем уменьшить до 5 Мб!) и превратился в НФ, который был сэкономлен исключительно HC в полном размере?!


Вот я и спрашиваю, есть реальные примеры, где применяется тобой выдуманный термин "эффективность кэширования", который <> "экономия" <> "эффективность программы" и его значение может превышать 100%?

Хм... Иду по твоей ссылке и читаю "русским по белому":
В технической литературе кпд иногда определяют т.о., что он может оказаться больше единицы. Подобная ситуация возникает, если определять кпд отношением W_пол/W_затр, где W_пол - используемая энергия, получаемая на "выходе" системы, W_затр - не вся энергия, поступающая в систему, а лишь та её часть, для получения которой производятся реальные затраты.

Я не формулу сейчас обосновываю (ее то как-раз можно вывернуть как душе угодно), а принцип - ведь ты оспариваешь именно сам принцип.
Эффективность кэширования (ЭК) - величина призванная показать насколько эффективно хранение в кэше данных. Большой кэш с редковостребуемыми данными менее эффективен, чем меньший по объему кэш, но с файлами, которые постоянно "в деле". Чтобы считать ЭК за весь период нужно знать общий объем кэша и сколько из него прочитано (и да, прочитано вполне может быть больше, чем в него помещено - теоретически). А чтобы считать суточный показатель мы можем оперировать величинами : "записано в кэш"/"прочитано из кэша" в течении суток - это я и предлагаю.

Посмотри (http://www.yandex.ru/yandsearch?rpt=rad&text=%22%FD%F4%F4%E5%EA%F2%E8%E2%ED%EE%F1%F2%FC+%EA%FD%F8%E8%F0%EE%E2%E0%ED%E8%FF%22) сам. В частности термин ЭК используется и в Squid'е и в ISA Server.

Поддерживаю равнение на "большие" программы, и администраторам со стажем будет понятно о чем речь идет в НС и новые пользователи получат цифры, аналогичные тем, что рассчитывают серьезные программные продукты (там я думаю не один десяток людей, не один год думал на алгоритмами)...

Хм... Ну, и дальше тогда уж прочти:
"При этом, хотя истинный кпд установки меньше единицы, рассмотренный кпд h = Wпол/Wзатр может оказаться больше единицы".


Читал я это и раньше, пытаясь найти примеры, когда "эффективность кэширования" может принимать значения больше 100%... Не нашел!
Везде натыкался на фразы типа:
"...Общая эффективность кэширования примерно 12,5%, но не за счёт TCP_HIT..."
"...эффективность применяемых механизмов кэширования может достигать 99%..."
"...эффективность кэширования внутренней кэш-памяти составляет почти 90  процентов..."
и т.д.


Так есть ли где-то в инете формулы расчета эффективности кэширования в "серьезных" программах (Squid'е, ISA Server и т.д.)? А лучше упоминания того, когда их значения могут превышать 100%?!
Ткните пальцем, дабы удовлетворить мою природную любознательность... ;)

Повторю уже сказанное: формулу можно вывернуть как душе угодно - можно и так, что не будет >100%

Особо не искал, но не видел.

В моем распоряжении точно такие же Яндекс и Google, как и у тебя самого.

Нашел в Документации по Microsoft ISA Server (http://www.isadocs.ru/docs/CMT_WProxyCounter.php) описание счетчиков производительности Web-прокси.

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

Вот вам и "невсерьез", "сарказм", "чушь", "бессмысленный расчет" и как там еще кое-кто обзывал мое предложение... :)


А вот подтверждений, что в "серьезных" программах эффективность кэширования может превышать 100% я так и не нашел!

После изучения документации "серьезного" ISA Server могу сказать точно, что там НЕТ показателей, принимающих значения > 100%! Собственно, там вообще нет показателей, хоть немного напоминающих формулу Rick'а... ;)

Я понимаю, что тебе во что бы то ни стало хочется доказать свою правоту, но может попробуешь таки _беспристрастно_ поразмыслить какое отношение Cache Hit Ratio имеет к экономии трафика? ::)
И пожалуйста, обрати внимание, на мои слова "Считать запросы - полезная функция для статистики." - ты малость припозднился с обидами (и пользуясь случаем прошу прощения если мои реплики тогда тебя задели/обидели). :) Но я делаю акцент на том, что запросы - в статистику, а в главное окно именно величину измерямую на основе всем понятных мегабайтов.

А хочешь шутки ради пример из не менее "серьезного" Squid'а, когда эффективность < 0? ;)

Плохо искал. Точнее искал то может и хорошо, да видимо исключительно аргументы в пользу запросов.  :'(

То, что предлагаю я (только не надо в пылу диспута уже приписывать мне какую-то формулу - я ее еще не успел придумать, а уже оказывается стал ее автором ;D) в Squide называется как Byte Hit Ratio, в ISA Server как Cache byte hit ratio.
Величина родственная с Cache Hit Ratio с той разницей, что полюбившейся тебе Cache Hit Ratio считает процент запросов, а Byte Hit Ratio считает вес/размер этих же запросов. Пользователь экономит как раз размер. Трафик пользователь экономит, а не неосязаемые "запросы"!

Нашел информацию (http://www.google.com/search?q=cache:bFDtbK1xtn4J:www.cs.ait.ac.th/ai3/research/iws99_pre/full.doc+byte+hit+ratio+of+Squid&hl=ru&ct=clnk&cd=38&gl=ru) и по не менее "серьезному" Squid'у. Эффективность там измеряется 2 показателями:


Вот реальный пример (http://mrtg.rz.uni-hohenheim.de/squid/requesthitbyteratio.1.html), где видно, что оба показателя не превышают 100%!

Первый показатель считается по запросам (как предлагаю я), а второй по трафику (как сейчас считает HC)...  :)


Читал и о таком старом варианте расчета в ФАКе 1999 года (http://www.squid-cache.org/mail-archive/squid-users/199912/0347.html): (client_bytes - server_bytes) / client_bytes , но и он никогда не превысит 100%!


Уже в двух "серьезных" программах (ISA Server'е и Squid'е) считается процент запросов! Странное совпадение? Ошибки их создателей?! ;)


Именно за счет того, что HC сам обрабатывает эти запросы, пользователь экономит трафик и время! Чем больше запросов HC сам обработал, тем выше его эффективность, как кэширующего прокси-сервера!
Не зря "серьезные" программы считают этот показатель!

---

Вопрос:
Так стоит ли добавлять в формулы расчета показателей эффективности, что "рассчитывают серьезные программные продукты", где "не один десяток людей, не один год думал на алгоритмами", свои спорные переменные, типа НФ и ТНЭ ?!

2 вариант. Думаю что также лучше считать секономленое время и общее врямя сидения за инетом. Это будет полезно модемшикам. А процент эфиктивности это сколько взято из инета а потом сколько из кеша вот и результат.

Сэкономленное время посчитать невозможно! Почитай тему с начала, уже обсуждалось!

Да, вопрос-ответ старый. Тем не менеее лежит в официальном текущем FAQ'е (http://wiki.squid-cache.org/SquidFaq/InnerWorkings?highlight=%28byte+hit+ratio%29#head-401a0ade283b4a6bf820fb85c149bbc7e7a24ea7) 2007года.

Мде... Ценность вопроса-ответа 99-го года ты ставишь под сомнение, а взамен вываливаешь инфу 95-98 годов. В чем прикол? (вопрос в общем-то риторический)

Укатайка! Плевать на все примеры - лишь бы они не показали > 100%? А отрицательный кпд (нагревая воду получаем кусок льда?) - это не интересно. Зациклился на "больше ста"? Ну вот пример (http://wiki.squid-cache.org/SquidFaq/InnerWorkings?highlight=%28byte%29%7C%28hit%29%7C%28ratio%29#head-a20eced79955a01c9e4a8c70e73f644a98cb0aec) с > 100%.
Что эти примеры доказывают? Да ничего собственно не доказывают: какой параметр и как нам _надо_ посчитать - так и посчитаем (чем все и руководствуются).

Я бы сказал, что ошибка "толкователя". Если кратко - Squid с ISA и HandyCache разного поля ягоды, а ты не задумываясь о смысле этого параметра для пользователя ограничиваешься только фактом существования этого параметра в "серьезных" прокси. Подробнее ниже.

И ISA Server и Squid имеют а) ограничение на размер кэша б) автоматическое удаление устаревших объектов из кэша.
Т.е. там кэш ограниченного размера всегда поддерживаемый в актуальном состоянии. И соотношение запросы из кэша / общее количество запросов (Hit Ratio) нам показывает насколько кэш удовлетворяет потребности: низкий процент показывает необходимость увеличить размер кэша/вообще включить кэширование. Высокий процент - что кэш близок к оптимальности по размеру и содержимому.  И... все, других выводов не сделать. И, кстати, ни слова про экономию. Ну не оценить по количеству запросов экономию - невозможно! Не считают экономию по количеству монет - считают по достоинству этих монет. Соотношением запросов оценивается эффективность имеющегося кэша, а не экономия от его использования.
А вот Byte Hit Ratio показывает процент "чистой" экономии - так же как сейчас в HandyCache, с той лишь разницей, что в) и Squid и ISA - прозрачные прокси: _весь_ трафик идет через них. И у них Byte Hit Ratio - это реальная эффективность/экономия, а у HC - не пойми что.

В нашем случае с НС мы имеем бездонный кэш, в котором может храниться все что угодно и сколь угодно долго. Какие выводы мы можем сделать из знания величины Hit Ratio (процента запросов)? Если Hit Ratio мал - значит мы еще не нагуляли достаточный кэш / у нас его вообще нет. А если высок - значит можно радоваться? А нифига нельзя! У нас может быть несколькогиговый кэш из которого 90% - мертвый груз. Может Hit Ratio нам это показать? В Squid и ISA - может и покажет, а в HC - нет. Т.е. не важно, отличный кэш или помойка - Hit Ratio покажет, что все великолепно. Т.е. в HC соотношение запросов не покажет ни эффективность кэша (в отличие от Squid'a и ISA), ни экономию - этого Hit Ratio в принципе не показывает.

И нынешний процент, и предлагаемый тобой процент запросов основаны на некорректных данных: считается процент от общего трафика, хотя общий трафик в расчете липовый; предлагается оценивать эффективность кэша, но ни количество объектов в кэше, ни их размер неизвестны.

---

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

Нужна конкретная формула? Пожалуйста:

Общий трафик (ОТ) - весь трафик запрошенный пользователем: внешний трафик + затребованное из кэша (MB).
Трафик не поддающийся экономии (ТНЭ) - все, что было передано клиенту без записи в кэш (MB).
Трафик поддающийся экономии (ТПЭ) = ОТ - ТНЭ (MB).
Взято из кэша (ВК) - взятое из кэша (MB).
Отношение кэширования (ОК) - то, что считаем.


Здесь исходные данные абсолютно точно поддаются определению - только то, что мы действительно можем посчитать. И никаких > 100% нет.

Пример: общий трафик 200М из которого - 40М трафик не поддающийся экономии (например https), 60М - взято из кэша. ТПЭ = 200 - 40 = 160М

Нынешний расчет:
Как не трудно заметить, если у нас нет трафика не поддающегося экономии (протоколов отличных от http и файлов, которые согласно правилам не помещаются в кэш) оба расчета покажут одинаковый результат.

Что нам показывает вычисленное значение? Говоря человеческим языком это "процент сэкономленного от того, что вообще можно сэкономить".
Какие выводы можно сделать смотря на результат? Низкое значение означает, что кэша вообще нет или он еще не накоплен, высокое (>50%) - что мы больше читаем из кэша, чем записываем в него. В автономном режиме значение -> 100%, при запрещенных чтении/записи в кэш -> 0%.

Пример вообще не о том! Там речь о "ratio of failed-to-successful requests", а не о "Request Hit Rate" или "Byte Hit Rate"!


И я о том же говорил в посте (http://handycache.ru/component/option,com_smf/Itemid,10/topic,158.msg2696/#msg2696), который ты выше уже цитировал: "Чем больше запросов HC сам обработал, тем выше его эффективность, как кэширующего прокси-сервера!"


А что нам покажет твой Byte Hit Rate в HC? Да тоже только то, что какие-то файлы читаются из кэша чаще, чем другие! А "мертвый груз" 90% в кэше в твоей формуле также никак не учитывается, т.к. в HC мы его учесть вообще не можем! Мы можем только его временами чистить из кэша.

Так что, и Byte Hit Rate в HC не отражает реальную эффективность использования всего того, что лежит в его бездонном кэше!


Вообще-то, я уже давно предлагал (http://handycache.ru/component/option,com_smf/Itemid,10/topic,158.msg2580/#msg2580) убрать из твоей первоначальной формулы НФ и перейти к варианту, который ты сейчас и озвучил в немного другой интерпретации ОТ (которая раньше не включала ВК)!
Рад, что помог осознать ненужность переменной HФ... :)

На слабые места такого подхода я также уже указывал:


Но ради высоких целей привлечения новых пользователей готов согласиться с твоей обновленной формулой расчета эффективности на пару с моей формулой эффективности обработки запросов... ;)

голосовал за 2й пункт

считаю что в статистике нужно показывать и сколько было взято из кэша
и тут же рядом показывать экономию

не буду предлагать никаких формул, но считаю что как минимум "304 Not Modified (HC)" нужно включить в расчет экономии

А не смущает, что "экономия" при этом может превысить 100% и потребуются лишние обращения к относительно медленному диску (MFT/FAT)?
Читал последние пару страниц этого топика?

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

Я уже предлагал:


но что-то не "прижилось"... ;) Да и величина эта получится относительно небольшой...

читал, и мое мнение полностью совпадало с мнением Ricka, до тех пор пока он не убрал из формулы учет НФ...может он случайно не вписал его туда ? =)
лично у меня за день в мониторе около 3/4 "Ответов" - "304 Not Modified (HC)"...экономия есть? есть, так почему она не должна учитываться? не хотите "накручивать", а занижать лучше чтоли?
и меня не смущают "лишние обращения к относительно медленному диску"...хотя бы опционально можно же сделать расчет с учетом этого?

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

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

Как оценить "экономию времени"? По максимальной скорости канала?

Это как "из пушки по воробьям"... :) Думаю, не стоит рассказывать, что максимальная пропускная способность канала часто не совпадает с реальной скоростью закачки в каждый конкретный момент времени! Скорость зависит от конкретного сервера, нагрузки на него в данный момент, настроек ограничения доступа на сервере, а также от провайдера, "ширины" его внешнего канала и его загруженности в данный конкретный момент и в конкретном направлении и т.д.

Т.е. даже приблизительно посчитать экономию времени мы не в состоянии!

Почему по максимальной? Считать реальную скорость в каждом запросе, проходящем к серверу, и усреднять. Тогда при оценке экономия времени на одном конкретном запросе может и не совпасть с гипотетическим реальным значением, а вот взятая по многим запросам совпадет.

Предложений по изменению методов расчёта масса. У меня только одно, которое будет наиболее полезно для меня: учитывать файлы взятые из кэша браузера (304 not modified). И ни в коем случае из Label->Caption "Взято из интернет" не убирать файлы загруженные единоразово(exe,zip,..) Иначе мы качаем из сети одно, программа считает только свой хлеб, и выходит, что трафик можно посмотреть только щёлкнув на свойство соединения по значку значку в трее. Думаю, что большинство считает так, да?

Если ты читал всю эту тему, то сам знаешь, что нет... ;)

 :)И жена, и друзья, и собака так считают :P
В этой ветке не много народа, значит кто-то даже не посчитал нужным суда обращаться - всех устраивает.
Если будут в новых версия функции в виде экономии времени :D
... сделайте галку, чтоб отключить можно было. У меня опыт обращения и с диал-апом, и с xDSL, сейчас выделенка. И никогда экономия времени не интересовала...
Меня больше волнует, что в мониторе горизонтальная полоса прокрутки улетает влево как только нажмёшь на ячейку таблицы в столбике "правило". Приходится растягивать главное окно по экрану "от уха до уха", чтобы посмотреть что же там за правило!

Ладно, всё это проблемы переходного возраста. :P

Ещё добавлю, что эта ветка-есть голосование, и на момент 16:30 06.04.2007 это моё мнение. Может изменится, поживём увидим. Лишь бы польза была. :)

Да простят новичка, но в ответ safistaction замечу, что эту тему прочитали более 2700 человек.
  Хотя простого обывателя более беспокоит Сколько он экономит денег, а не байты и их способы подсчёта. А сам лично полностью согласен с Rick в методе подсчёта экономии трафика. Такой подход более точен и рационален.


       ____________________________________________________________
                                      Мы имеем то, что имеем....
 

blakjocer
ты пользователь диалапа? Есть же всякие дайлеры, которые считают с учётом всех выходных и т.д.

Для меня в начале был важен расчёт экономии(как только установил прогу взамен КулПрокси). И много было недоразумений, в обсуждении которых помог модератор DenZzz.
Потом, когда проблемы были ликвидированы, я увидел что экономия х%, а в мониторе все записи "302". Ну дык всё ясно! Лучшего результата получить... не знаю как. Правила придумывать по размеру реферата? Так придумывайте! Смотреть на экономию, чтобы её просто узнать - красивые циферки? Эта прога экономит по максимуму, весь алгоритм обработки её событий изложен в факе. Чего ещё ждать? Кроме улучшенных правил-ничего!

Я клоню к тому, что расчёт экономии для людей не позволит получит представление об экономии. Это азарт. Просто азарт. Если мне скажут, что вода из кэша будет литься меньше, то реже мыться я не стану. А в кэширующем прокси главное удобство управления, наглядность, дружественность интерфейса. А правила пишите сами, если не нравится.

Извините если сумбур.

Лишь бы польза для россиян была.

Народ, а знаете почему на форуме так много недопониманий с вопросом" Типа что у меня так мало трафика из кэша берет" .. Мы выяснили, что HC не учитывает с ответом /304 Not Modified (HC)/. ... а это зря..ведь при открытии любой страници, уже занее посещенной, графика с него не загружается, выдавая ответ в HC /304 Not Modified (HC)// А ведь это экономия, ведь реально браузер не загрузил повторно эту картинку с сайта, значит сэкономил на этом изображении...поэтому считаю предложение обоснованным  считать в экономию то, что браузер взял из своего кэша, а от НС получил только подтверждение актуальности файла /304 Not Modified (HC)/. Сразу уйдут все недопонимания..т.к. этот реально сэкономленный трафикбудет учитываться в HC, что экономия будет на лицо!

HC не может залезть в кэш браузера. Следовательно посчитать эту экономию мы не сможем.

Как сделать, чтобы файлы, загружаемые с ссылок вида: http://forum.doom55.ru/index.php?act=attach&type=post&id=7934 не считались как трафик и не загружались НС в кэш?

Чтобы эти файлы не писались в кэш, добавь в "Белый список" правило:
#10#~#True#~#forum\.doom55\.ru/index\.php\?act=attach#~##~##~#False#~#True#~#False#~#False#~#False#~#False

А чтобы они не считались за трафик - с этим тебе в тему: "Нужен ли расчет экономии и в каком виде? (http://handycache.ru/component/option,com_smf/Itemid,10/topic,158.0/)". Там не так давно уже горячо обсуждалось, что надо считать, а что нет!
Туда же пойдет и твоя тема...

Считать экономию ИМХО нужно ту что можно подсчитать, ведь цель - подсчитать экономичность использования интернета... и если человек качает фильмы с инета гигабайтами, и один раз в месяц ходит по форумам, никакой речи об экономии быть и не может трафик то и тот и тот дорогой, экономию которого и хочется подсчитать. Так же непонятно как быть с подсчетом заблокированных элементов, ведь это тоже экономия но подсчитать её не представляется возможным, посему программа должна считать экономию интернета только того который через нее проходит, причем всего! Да, и бывают еще ситуации когда стоимость интернета делится на интернет и локалка, при этом пользователь часто лазит по локалке где трафик бесплатный но браузер настроен на использование хендикеша(в локалке тоже может быть много рекламы) и исключения не каждому хватит терпения прописывать в браузер а это одозначно портит статистику которую хотелось бы увидеть чисто по интернету.
Че хотелось сказать ... все это относительно, поэтому считайте как есть - абсолютные цифры в статистике есть и всегда при необходимости можно пересчитать, возможно для этих целей будет удобно сделать экспорт в эксель.

Почитав ру-борд, возникла такая мысль: можно в Белый список добавить новую колонку - "Статистика", с помощью которой каждый сможет сам для себя решить, что он лично хочет учитывать в статистике, а что нет.

ИМХО, это будет самое компромиссное решение для всей этой темы...

DenZzz
Не понял мысль. Что именно держать в колонке "Статистика"?

Галки. Есть галка - не учитываем в статистике. По аналогии с отключением проверки других списков через Белый.

Что это дает? Статистика ведь будет необъективной.

Она и сейчас необъективна (см. 5 страниц выше)! Но зато каждый сможет приблизить ее к своим личным потребностям:
- кто-то не хочет считать трафик, который не пишется в кэш (т.к. на нем нельзя сэкономить);
- кто-то не хочет считать трафик с локальных ресурсов провайдера (т.к. он бесплатен);
и т.п.

Все это можно будет сделать через новую колонку в Белом списке...

Монитор показывает сколько взято с инета, сколько взято из кеша. По моим наблюдениям из кеша берется всего лишь 10% трафика. И кажется что эконочится не так уж и много трафика.
Реальная польза от handycache как раз в блокировании банеров. Причем эта польза никак не отображается, пользователь не подозревает что почти 50% трафика экономится блокированием банеров, потому что ему не предоставляется информация о том сколько трафика он таким образом сэкономил.

Это была бы офигенная реклама, если бы писало сколько кб банеров было заблокировано. Я не знаю насколько это реализуемо, но помоему можно узнать размер контента(банера) по http, и не скачивая его.

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

Определенный резерв все же есть. Можно учитывать заблокированные файлы, для которых известна их длина (или файл есть в кэше, или в ответе указан Content-Length). Здесь свой вклад в статистику будут вносить блокирующие скрипты, Черный список, а также опция 'Не загружать большие файлы'.

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

Лишнее обращение к диску после срабатывания "Черного списка" только ради выяснения размера файла для красивой статистики меня лично не радует!

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

А несколько срабатываний опций 'Не загружать большие файлы' на каких-нибудь гигабайтных фильмах, когда пользователь, не поняв причину блокировки, вновь и вновь жмет F5 - быстро накрутят статистику до 100% экономии! Я не думаю, что это правильно. Если большой файл действительно нужен, то он все равно будет принудительно закачан. А если файл не нужен, то начав закачку и увидев ее конечный размер, пользователь сам бы нажал в браузере на "Отмену". Поэтому говорить в этом случае о многих сэкономленных мегабайтах или даже гигабайтах, ИМХО, большое лукавство...

Если длина файла кэша неизвестна, делать лишние обращения и не предлагается. Кстати, благодаря сриптам запросов она очень часто известна.
Здесь непонятно. Я веду речь про заблокированные файлы. А ты?
Гм... Тот же настойчивый пользователь, думаю, вновь и вновь будет жать F5, пока не поймет, что находится в ненужном ему оффлайне. Но поздно - "экономия" уже просчитана.
А еще он будет зажимать горячие клавиши для переобновления загруженных только что из кэша устаревших страниц (элементов страниц), не подозревая, что вызов этих ненужных ему и требующих срочного обновления данных засчитан в экономию от кэширования.
Или, к примеру, пользователь с ограничением "Не загружать большие файлы" давит скачивание видео (которое оказывается гигабайтным) и получает его из общего кэша пользователей фирмы. Рассчитанная экономия огромна, почти 100%, а на самом деле в случае отсутствия этого файла в кэше пользователь не скачал бы ничего.

К счастью, как в свое время уже обсуждали в этом топике, к экономии процентный показатель в статистике отношения не имеет. Не предлагал считать экономию от заблокированных файлов и я. Имхо, полезно считать сходный "кэшевому" процентный показатель блокированного:
% = Блокировано/(Взято из интернет+Взято из кэша+Блокировано)*100

В последней бете HC длина заблокированного файла в кэше известна очень редко! Если точнее, то только для файлов с неизвестным расширением при условии, что они есть в кэше. А как показывает практика, довольно редко рекламные баннеры имеют статичный URL...


Да и я про них. Хотел cказать, что скрипты ответов блокируют файлы известной длины не так уж и часто. Большая их часть приходится на долю скрипта block_long_file.lua , о котором мы уже говорили отдельно.


Проблема в том, что размер блокированных файлов очень часто будет неизвестен! Как быть? Не учитывать их совсем? Тогда какой смысл считать показатель блокированного, в котором многое из заблокированного не учтено!?


P.S. Помню, раньше я уже предлагал считать показатели эффективности не по трафику, а по количеству запросов. По-прежнему считаю, что это самая адекватная методика оценки эффективности работы HC...

"Как вы яхту назовете, так она и поплывет". Здесь, имхо, не угнаться за званием "всего заблокировано...". Тут ближе к "заблокировано как минимум...". Но это уже показатель работы блокирующей подсистемы, который, имхо, лучше, чем никакого показателя.
Показатели "по трафику" и "по количеству запросов" не взаимоисключают друг друга. Имхо, они способны существовать параллельно и для кэширующей, и для блокирующей подсистем.

ХК пишет взято из инета 19.21
из кеша 12.70/ 39.8%
вот хотелось бы узнать как вычисляются эти проценты

12.7/(19.21+12.7)

а тогда небольшое предложение по улучшению:
на пример в хк стоит сохранять файлы в кеш не более 2 мб.
если просто читать в инете странички то этот процен показывает эффективность кеша,
но если качать файлы (от 2 мб) то тогда этот процент резко падает и что показывает уже не понятно
Может быть стоит файлы которые больше максимального размера файла в кеше не учитывать при рассчете процента
или ввести другой процент (показатель). а то допустим если хк работает пару дней то смысл в этих процентах никакой, и не понятно насколько эффективен кеш

Управление загрузкой - Не загружать большие файлы - Предельный размер
а это что по вашему?

Добавлено: 22 Сентября 2009, 21:58:05

а смысл? зачем считать как-то по особенному, если, в конечном счете, нам нужно знать всю экономию?

это я для примера, а не предложение
Смысл в том, что когда я вижу что взято из кеша 0.08% то это как то мало, но при этом я учитываю что скорее всего тут учтены и файлы по 100 мб и которые по сути из кеша то и нельзя взять (так как стоит ограничение файлы больше 2мб не кешировать) а знать хочеться сколько именно релаьно я беру из кеша скажем так при простом чтении новостей. но из за закачек которые идут паралельно я этого не вижу.

Извиняюсь заранее что вмешиваюсь в обсуждение, лично меня процент устраивает, о чем и голосовал. Но если вопрос коснулся и обсуждение горячее на несколько страниц, хочу внести свое скромное предложение. Процент можно сделать опциональным. А расчет экономии вообще (теоретически) можно заваязать на самостоятельную подстановку формулу. Опять же, теоретически, можно пользователю предоставить несколько предопределенных переменных и пусть он себе пишет некую формулу исходя из них. Я понимаю что мое предложение слегка накручено, но раз уж столько вариантов разных, такой бы, вероятно , всех устроил. Не бейте ногами :)

flash

Ты опоздал! Обсуждение было горячим три года назад и уже не актуально, т.к. теперь с помощью расширения можно указать, какой трафик не брать в расчет экономии.

Готовое расширение входит в комплект со свежими версиями HC, а обсуждается в теме:
IgnoreTraffic - расширение для управления подсчетом трафика (http://handycache.ru/component/option,com_smf/Itemid,10/topic,2621.0/)

Если оно чем-то не устраивает, то можешь написать свое расширение и считать трафик, как тебе нравится.

P.S. Тема и голосование закрыто.