Да, вопрос-ответ старый. Тем не менеее лежит в официальном текущем FAQ'е 2007года.

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

Укатайка! Плевать на все примеры - лишь бы они не показали > 100%? А отрицательный кпд (нагревая воду получаем кусок льда?) - это не интересно. Зациклился на "больше ста"? Ну вот пример с > 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%.

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

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

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

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

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

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

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

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

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


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

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

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