Форум PHP

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

1. Под фоновым режимом я подразумевал cron (об этом говорил раньше), которым можно запускать скрипт-обработчик раз в сутки или раз в час - в зависимости от активности.
Ну и кнопочка для ручного запуска не помешает, чтобы конвертировать самые свежие обновления. У меня , например, так сделано отслеживание и ведение таблицы "провайдеров" (максимально подробной информации о посетителе: страна, город и т.д.).
Кстати, в самом начале этой темы говорилось о возможности отслеживания с точностью до пользовательского компьютера. Неужели такое реально возможно (при динамическом IP) ?

2. Мой пример про RTCOMM неудачен, приношу свои извинения.
При внимательном изучении оказалось, что эта контора скрывается за брэндом Rambler :-)
USER_AGENT начал копить недавно. Когда накопится статистика и обнаружатся новые активные роботы и поисковики - непременно обнародую.

3. Полностью согласен. Потребности разные. У хостеров - одни, у вебмастеров - другие.
И сделать универсально сложно - получится этакий монстр, который к тому же будет требовать постоянного обновления (аппетит приходит во время еды).

1) А фон кто будет создавать, администраторы зачастую неделями в систему администрирования не лазят их может очень много накопиться.
2) Роботов сколько угодно можно учесть, мы учли только интересные для себя, если у вас имеется USER_AGENT и вы скажете, что это за робот - мы с удовольствием включим его в систему.
3) Да функциональность можно улучшить значительно, с этим полностью согласен. Та функциональность которая есть опеределяется предпочтениями разработчиков, мы разрабатывали те инструменты, которые нам самим в первую очередь необходимы. SoftTime не нужны были инструменты по определению времени посещения страницы, но они были нужны Loki - он их разработал и мы включили его в счётчик. Наличие той или иной функциональности определяется потребностями разработчиков и лоббированием на форуме :)))

Ну да, если делать запросы к текстовым полям непосредственно при выводе статистики, то медленно будет. Но что мешает сделать в фоновом режиме формирование средствами MySQL из текста USER_AGENT полей с SETами . А в статистике работать уже с ними.
При этом обработчик становится более гибким, т.к. первичная информация не теряется.
Вот сейчас в счетчике есть некий набор поисковиков, и только они фиксируются, но ведь реально их гораздо больше, и появляются новые.
Например, самый активный робот в Рунете - RTCOMM, который пишет абсолютно все, каждый чих (с совершенно понятной целью). Учитывает его PowerCounter ?

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

А сравнивать вещи с разными пользовательскими возможностями - не вполне корректно.

Понимаете, Вы приводите спорные аргументы и делаете скоропалительные выводы.

>А представьте, сколько будет весить ваша БД через год, если она используется для хранения (например как у меня) форума, статиста, баннероротатора и еще кой-чего по мелочи? Что, прийдется целиком менять движок?
1. Разбор данных непосредственно в счетчике никак не влияет на размер базы.
2. Данные, разложенные по таблицам, занимают много меньше места, чем исходные данные.

> А чем толще скрипт, тем дольше он будет обрабатываться.
Разумеется это так. Но вопрос: на сколько больше? Десятые доли секунды, на мой взгляд, вполне приемлемо.

>Или другая ситуация, порядка нескольких десятков/сотен почти одновременных запросов на сервер (довольно частая ситуация в случае форума или чата), а это вполне реально при пике суточной посещаемости проекта в 1000 и даже менее человек?

На самом деле нет. 1000 посетителей в день – это мизерная нагрузка на сервер. Вообще следует говорить не о посетителях, а о хитах.
А вот несколько десятков/сотен одновременных запросов (хитов) – это очень, очень посещаемые ресурсы. 1000 посетителей в день – это очень и очень далеко от десятков/сотен одновременных хитов. Такие популярные ресурсы большая редкость. Для них нужны отдельные сервера и, конечно, другие счетчики.

>а вот административная часть как раз может и потерпеть (учитывайте разницу между продавцом и покупателем
Покупателем, в данном случае, является и администратор сайта. Ведь он выбирает себе систему учета посещаемости.

>А пререименовать файлы Вы не пробовали?
Это невозможно. Вы же не предлагаете написать в readme к счетчику: Уважаемые пользователи, если вы хотите защитить админ директорию, то переименуйте все файлы счетчика и исправьте все пути во всех файлах. :)
К тому же это не защита – это ее видимость, в отличие от паролирования директории средствами htaccess: очень просто делается и обеспечивает хорошую надежность.


>А в том то и вся проблема - счетчик и статист в одном файле...
Мне кажется, что обозначенная Вами проблема немного надуманна. Есть ли у Вас примеры того, что выполнение скрипта счетчика вызывает задержки формирования страницы более десятых долей секунды?

Хранили мы USER_AGENT в базе - слишком долго разибирается, поэтому раскидали эту задачу по пользователям - пока это никому не мешало, так как count.php выполняется очень быстро (для меня не приемлемое время выполнение такого скрипта как count.php - больше 1-2-х секунд). В конце концов, чем не повод создать такой же функциональный счётчик только на другом движке и конкуренция будет и выбрать будет из чего :))) и мы его с удовольствием выложим в разделе downloads (если положить некуда будет).

Ну тут нас сразу подстерегают трудности: необходимость крона и много процессорного времени сразу.
Если можно нагрузку раскидать на тысячи частей (где добавится всего 0,05 сек), то мне кажется это лучшим выходом по сравнению с тем, чтобы все попытаться обработать разом.
Исключение - тот единственный случай, когда нагрузка и так слишком большая.

Ну вот, сразу - давай готовый код...:-)
А что же , идеи подавать и обсуждать в этом форуме возбраняется ?
Ведь эта тема посвящена как раз идеологии построения счетчиков, а не конкретным строкам кода.
Вы говорите: "Именно так сейчас и происходит".
Да нет, не так, к сожалению. Все делается в скрипте count.php. Именно из него можно и нужно убрать лишнее и выполнять отдельным скриптом, запускаемым cron'ом.
Причем структуру таблиц можно не менять (только добавить одно текстовое поле для USER AGENT).
Что касается написать готовые коды, то есть проблема: очень трудно обеспечить совместимость с существующими кусками текста, да еще и придерживаясь принятого стиля программирования (это - вещь субъективная, поэтому комментировать не буду).
Поэтому фактически придется все переписывать, но тогда это будет совсем другой продукт.

А с объявленной целью PowerCounter согласен :-)

>А все эти разборки с формированием дополнительных таблиц, упрощающих и ускоряющих
>администрирование , можно ведь выполнять не в теле счетчика (а значит и в теле документа),
>а отдельным скриптом под cron'ом ночью.
>При таком подходе и волки будут сыты и овцы - целы...:-)
Именно так сейчас и происходит, всё что можно выполняется в системе администрирования, archive.php можно (и рекомендуется) подключать к cron.

PS Вообще, код который лежит на www.softtime.ru не является эталоном и даже не является конечной продукцией, downloads изначально планировался как склад блоков-полуфабрикатов. Можно использовать, можно нет, а можно взять и переделать - если возникают затруднения, спросить на форуме, всегда поможем. В конце концов, PowerCounter это пример того каким может быть счётчик и его основная цель вдохновить других на работу или освободить от лишней работы, если она кажется скучной.
PS Если вы хотите конструктивных изменений давайте готовый код. Не нравится блок - заведите тему, предложите своё решение, именно так поступал Loki и подавляющая часть его нововведений была внедрена или будет внедрена в ближайших версиях на радость всем пользователям.