Журналы сервера / Webalizer, 206 частичного контента для аудио и видео файлов - как рассчитать количество загрузок?

Question

Мне нужно рассчитать количество скачиваний видео и аудио файлов с нашего медиасервера. Наш медиасервер содержит только аудио / видео файлы (mp3 и mp4), и мы анализируем наши файлы журнала IIS ежемесячно с помощью Stone Steps Webalizer.

Когда я просматриваю статистику Webalizer, большинство «хитов» - это «частичное содержание кода 206», а большинство остальных - «код 200 нормально». Так, например, наши последние ежемесячные статистические данные Webalizer выглядят примерно так -

Всего просмотров: 1 600 000 Код 200 - хорошо: 300 000 Код 206 - Частичное содержание: 1 300 000

Общее число обращений намного больше, чем я ожидал, по отношению к объему обслуживаемых данных (Всего Кбайт).

Когда я анализирую файлы журнала, создается впечатление, что медиаплееры (iTunes, Quicktime и т. Д.) Создают несколько 206-х для одной загрузки / воспроизведения, и я подозреваю, что Webalizer не группирует эти несколько 206-х с одного и того же IP / посещения и вместо этого записывает каждый 206 как «хит» - и из-за этого общая цифра хитов сильно завышена. На вики-странице есть критика Weblizer, которая подтверждает это - http://en.wikipedia.org/wiki/Webalizer

Правильно ли я верю в отношении 206-х и Webalizer, и если я прав, то как рассчитать количество загрузок? Существует ли методология промышленного стандарта и / или существуют ли альтернативные приложения веб-аналитики, которые лучше подходят для этой задачи?

Любая помощь или совет будет высоко ценится.

Answer 1

Не получил никакого ответа на мой вопрос, но думал, что я дам обновление.

Мы проанализировали выборку наших файлов журналов за час и провели некоторое тестирование различных браузеров / медиаплееров наmp3 и mp4 файл.

Вот наши выводы -

• Некоторые медиаплееры, в частности iTunes / Quicktime, генерируют серию из 206 запросов, но не генерируют запрос 200.

• Большинство, но не все веб-браузеры (за исключением Chrome), генерируют запрос
  200 и 206 запросов при загрузке медиа-файла, т.е.
  загрузка на рабочий стол, в отличие от воспроизведения внастольный мультимедийный проигрыватель
  или подключаемый модуль мультимедийного проигрывателя

• Если файл кэшируется браузером / мультимедийным проигрывателем, он может выдать 304 запроса, а не 200 и не 206.

Учитывая вышесказанное, мы считаем невозможным подсчитывать «загрузки» медиафайлов из анализа файлов журнала, если в программном обеспечении не предусмотрен интеллектуальный алгоритм, разработанный специально для этой цели.Например, потребуется сгруппировать все запросы для определенного мультимедийного файла с одного и того же IP-адреса в течение установленного периода времени (скажем, 30 минут) и посчитать его как одну загрузку.Насколько мне известно, на рынке нет программного обеспечения для анализа файлов журналов, которое могло бы предложить такую ​​функциональность.

Я сделал быстрый поиск в Google, чтобы узнать больше об анализе подкастов / видео-метрик / файла журнала, и это действительно очень реальная, хотя и нишевая проблема.Google Analytics и другие инструменты веб-метрик, которые используют веб-маяки, например SiteStat, не подходят, если ваши медиафайлы доступны только для загрузки с вашего веб-сайта, т. Е. Нет синдикации RSS или iTunes и т. Д. Даже тогда я не уверен, что они могли бы сделатьработа.

Я думаю, именно поэтому такие компании, как podtrac и blubrry, предлагают специализированные инструменты измерения подкастов и видео с использованием перенаправлений, а не анализа файлов журналов.

Podtrac http://podtrac.com/publisher/measurement

Blubrryhttp://www.blubrry.com/podcast_statistics/

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

Answer 2

Это, вероятно, слишком поздно, чтобы помочь вам конкретно, но если вы проанализировали журналы своего сервера и сохранили их где-то разумно, например, в СУБД, быстрый кусочек SQL даст вам объединенные результаты, к которым вы стремитесь.Учитывая очень простую таблицу журнала, где каждые 206 записываются с «временем обращения», IP-адресом конечной точки и идентификатором / внешним ключом выбранного элемента, вы можете выполнить этот запрос:

select min(hit_time) as hit_time, ip_address, episode_id
from podcast_hit
group by DATE(hit_time), ip_address, episode_id

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

Answer 3

Попробуйте мое программное обеспечение. Я столкнулся с той же проблемой, когда mp3 разделялся на несколько потоков для IPod и Iphones. Это действительно легко реализовать и работает удовольствие.

Github