Форум PHP

Здравствуйте! В первую очередь хочу предупредить (и пояснить), что данный текст пишется не для того, что бы охаять создателей PowerCounter'а, глубоко мной уважаемых, а наоборот, помочь в улучшении данного продукта.

Для начала приведу цитату из описания продукта :
"Вы не ограничены выбором места размещения этой конструкции. Догружает посетитель страницу до конца или нет не имеет ровным счётом никакого значения - он будет подсчитан. Это связано с тем, что PHP-код выполняется на сервере и пока не будет выполнен, клиенту ничего отправлено не будет. Поэтому когда посетитель получает только первые байты, он уже учтён."

Ребята! Ну ведь это очевидная глупость! Если перенести эту картинку из виртуала в реал, то выглядеть это будет примерно так:Представьте себе современный автосалон с большим количеством продукции. По перефирии территории находятся камеры видеонаблюдения, фиксирующие посетителей. Но сами двери в салон заклинило...То есть люди приходят, камеры их фиксируют (они уже в статистике посещений ;-]), а в салон люди попасть не могут. А теперь представьте себе директора этого салона, просматривающего статистику и довольно потирающего руки со словами "клиентура так и валит". Как можно назвать данного человека? В лучшем случае дураком...

Не забывайте, что более важно не просто привлечь посетителя, а ЗАСТАВИТЬ ЕГО ЗАДЕРЖАТЬСЯ И ВЕРНУТЬСЯ!

Теперь о том, к чему это я. Разобравшись в коде PowerCounter'а, я пришел к неутешительному выводу - допущена ОГРОМНАЯ ошибка. Ребята, Вы зря соединили в один файл и скрипт сбора статистики, и скрипт ее обработки. Ведь при увеличении вставляемых данных увеличивается время загрузки страницы. То есть к примеру моя индексовая страничка весит (без графики) 8 КБ, да плюс ваши 11 КБ - время загрузки здорово возрастает. А если еще учесть, что на время выполнения скрипта впрямую влияет и размер датабазы (где-то у Вас на форуме наткнулся на фразу "у меня весит 2ГБ"), то становится вполне очевидным, что действительно, не каждый дождется загрузки страницы, а если и дождется, то отнюдь не в радужном настроении.

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

Поясню на примере - из поля USER_AGENT выуживается информация об операционке, браузере посетителя, бот он или человек. Поле HTTP_REFERER содержит так же информацию о принадлежности к поисковым системам (и менеджерам закачек), запросы в поисковых и собственно сам рефер, соответственно из 7-ми мы имеем уже 5 лишних таблиц...

При переносе обработки во внешнюю конструкцию и удалении лишних таблиц, мы получаем экономию 60%-80% места базы данных и 4-12 секунд экономии в загрузке страниц. В случае же того счастливца с 2ГБ-ной базой мы получаем экономию ~1,5ГБ места и ускорение загрузки раз в 10, а то и больше...
Неплохо, правда?

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

Повторюсь еще раз, но данный текст пишется не для того, что бы охаять создателей PowerCounter'а, глубоко мной уважаемых, а наоборот, помочь в улучшении данного продукта. Давайте придерживаться здоровой критики и самокритики (если кто-то найдет ошибки или недочеты в данном решении проблемы, то с удовольствием выслушаю их от Вас).

Помните, дурак не тот, кто совершает ошибки, а тот, кто на них не учится и повторяет их...

Немного отойду от темы и предложу еще пару улучшений к программе (повторюсь, в целом она мне очень нравится) в дополнение к изложенному выше и написанному мною в http://www.softtime.ru/forum/read.php?id_forum=1&id_theme=11746:

Кроме идентификации посетителя по REMOTE_ADDR, можно добавить его идентификацию по REMOTE_HOST и REMOTE_PORT. О том, для чего это нужно, я постил в http://www.softtime.ru/forum/read.php?id_forum=2&id_theme=11878

Так же в информационных целях прилагаю статейку (25 КБ), в которой рассматривается, что, кому и зачем нужно считать.

К вопросу о защите админ-директории от случайного (или не очень ;-)) ламера : из админ-директории уберается индексный файл, а в .htaccess прописывается запрет на листинг файлов в случае отсутствия индекса. В случае паролирования директории мы имеем шанс нарваться на инициативного балбеса, и рано или поздно (в зависимости от его упертости и опытности) он прорвется в защищенную директорию. В моем же случае - ему всего навсего выведется страница 404, и он со спокойной совестью пойдет дальше, понятия не имея о том, что его обманули так называемой "защитой от дурака".

С уважением, искренне Ваш, Дмитрий "DrDeath" Медянцев.

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

>Как можно назвать данного человека? В лучшем случае дураком...
Посмотрите отчет "глубина просмотра" и, заодно, "время сеанса" - из них как раз видно кто из клиентов задержался, а кто "не пошел дальше дверей".

Ну а в целом - все верно - скрипт счетчика можно и нужно разгрузить.

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

>То есть к примеру моя индексовая страничка весит (без графики) 8 КБ,
>да плюс ваши 11 КБ - время загрузки здорово возрастает

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

Я скажу более прямо: счётчик даёт 0 Кб к странице, так как посетитель качает только HTML, единственное, что он делает - это потребяет дополнительные ресурсы сервера.

А я поддержу DrDeath:
В необозримом будущем, счетчик должен писать только первичную информацию, а разбирать и раскладывать по таблицам уже потом. Другой вопрос, что актуально это только на ресурсах с большой нагрузкой и при этом мы потеряем в гибкости анализа информации. Иными словами, сейчас мне фиолетово формируется страница 0,1 секунды или секунду - клиент ее выкачивает все равно дольше.
Ну а большие проекты... большие проекты требуют больших вложений. Так что под заказ счетчик можно и оптимизировать:)

В больших проектах лучше использовать внешний счётчик - сервер и так работает под большой нагрузкой - удваивать её не рационально - лучше нагрузить ещё один сервер, идиально вообще чужой, вроде Rambler.

.

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

>Ребята! Ну ведь это очевидная глупость! Если перенести эту
>картинку из виртуала в реал,
Ничего не глупость. Счетчик считает обращения к странице, а не количество людей ее прочитавших. Я ведь могу и в автосалон подойти к двери, увидеть, что там оказывается машины, развернусь и уйду не заходя. Поэтому все заинтересовавшиеся ВООБЩЕ ДВЕРЬЮ должны быть учтены. В ИНТЕРНЕТЕ ВСЕ ДВЕРИ ОДИНАКОВЫ!!!

>можно назвать данного человека? В лучшем случае дураком...
Вряд-ли. В жизни если есть дверь, то найдется проходящий мимо, который и заглянет туда. В интернете КАК ВЫ САМИ заходите на разные сайты? По ссылкам, по поиску, по рекламе. У меня 4 месяца выложен сайт, но он в процессе постепенного развития (я не готов его еще раскручивать). Зайти может кто угодно - ничего не скрыто. Так вот счетчик мне точно говорит - НИ ОДНОГО человека! А вот на другом сайте он мне говорит 200 человек зашло - 150 через 1 минуту ушло (ошиблись дверью).

>а ЗАСТАВИТЬ ЕГО ЗАДЕРЖАТЬСЯ И ВЕРНУТЬСЯ!
А вот на ЭТО счетчик НИКАК не влияет! Это ВАША забота сделать интересное содержимое.

> То есть к примеру моя индексовая страничка весит
>(без графики) 8 КБ, да плюс ваши 11 КБ - время загрузки
>здорово возрастает.
Здесь даже я уже разобрался: как грузилось 8 КБ, так и БУДЕТ 8 КБ. РНР никуда не грузится, он выполняется НА СЕВЕРЕ. А размер самой датабазы тем более на загрузку HTML не сказывается.

>Как же это решить?
Исходя из вышесказанного - никак.

>Давайте
>придерживаться здоровой критики и самокритики (если кто-то
>найдет ошибки или недочеты в данном решении проблемы, то с
>удовольствием выслушаю их от Вас).
На это я тоже надеюсь.

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

>При переносе обработки во внешнюю конструкцию и удалении лишних таблиц, мы получаем экономию 60%-80% места базы данных и 4-12 секунд экономии в загрузке страниц. В случае же того счастливца с 2ГБ-ной базой мы получаем экономию ~1,5ГБ места и ускорение загрузки раз в 10, а то и больше...

> удалении лишних таблиц
> В случае же того счастливца с 2ГБ-ной базой мы получаем экономию ~1,5ГБ
Неправильный вывод. Во первых, лишних таблиц там попросту нет.
И даже если бы были… Механическое их удаление совсем не означает уменьшения объема хранимых данных.

>4-12 секунд экономии в загрузке страниц
Неправильный подсчет. Счетчик добавляет к загрузке страницы доли секунды… если, конечно в качестве сервера не используется 486 компьютер.

>>А если еще учесть, что на время выполнения скрипта впрямую влияет и размер датабазы
В случае скрипта счетчика (не статистика), размер базы, практически, не влияет на время выполнения.

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

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

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

Более точная идентификация посетителя нужна за тем, что бы снизить искажения статистики. Вот поисковых ботов из общей кучи же удалили, так почему бы не смотреть за тем, кто и как заходит. Имея динамический IP можно за каких-то 10-20 минут устроить иллюзию массового наплыва посетителей, а на деле это будет один человек. О реальности такой ситуации говорит такое явление как "дисконнект" - человек всего-навсего возвращается к просмотру сайта, а воспринят он уже как новый посетитель. А даже если таких случаев будет несколько процентов (например 1-5 из 100 или даже меньше), в целом это уже исказит статистику достаточно сильно.
За сим пока все. Всегда открыт к диалогу.

>Уважаемые собеседники! Вы абсолютно забываете, что сайты
>пишутся не для самих админов, а для посетителей
Мы об этом никогда не забываем. Если бы работа PowerCounter отражалась на удобстве посетителей - мы бы от него отказались не задумываясь.

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

>А представьте, сколько
>будет весить ваша БД через год, если она используется для
>хранения (например как у меня) форума, статиста,
>баннероротатора и еще кой-чего по мелочи?
Можете нам не рассказывать :))) - мы это очень хорошо представляем, гланая наша база колеблется от 10 до 400 Мб

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

>По этому чем более оптимизированный код будет выложен, тем меньше работы с ним в будущем...
Теория... А практива такова: Сервер P200. Кроме моего, на нем крутятся еще около 7 проектов. Генерация страницы (вместе со счетчиком) 0,15сек.
Думаю, на этом тему можно закрыть.

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

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

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

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

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

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

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

>Защита от дурака потому так и называется, что она только от
>дурака. Исходные коды счетчика выложены в свободный доступ.
>Желающим получить доступ даже не нужно пытаться перебирать
>названия страниц.

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

>В случае скрипта счетчика (не статистика), размер базы,
>практически, не влияет на время выполнения.

А в том то и вся проблема - счетчик и статист в одном файле...

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


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

>Поясню на примере - из поля USER_AGENT выуживается информация об операционке,
>браузере посетителя, бот он или человек. Поле HTTP_REFERER содержит так же информацию
>о принадлежности к поисковым системам (и менеджерам закачек), запросы в поисковых и
>собственно сам рефер, соответственно из 7-ми мы имеем уже 5 лишних таблиц...
Мы именно с этого и начинали. Поверьте, что с нерасчленённым USER_AGENT работать просто невозможно. 1000 хитов сделают обработку статистики просто не реальной. Вы можете нам верить, мы разрабатываем счётчик уже больше двух лет и сталкивались со множеством подводных камней - это один из них, любые операции со стороками в базе происходят очень медленно.

>Ребята! Ну ведь это очевидная глупость!
Это объективная реальность внутреннего счётчика, если вы хотите фиксировать все хосты и хиты - по другому не напишите, если не нравится - следует использовать внешние счётчики, но они не досчитывают примерно 20%, а насколько примерно зависит от аудитории и от того включает она картинки или нет. Будте аккуратнее в словах...

>Теперь о том, к чему это я. Разобравшись в коде
>PowerCounter'а, я пришел к неутешительному выводу - допущена
>ОГРОМНАЯ ошибка. Ребята, Вы зря соединили в один файл и
>скрипт сбора статистики, и скрипт ее обработки.
Должен отметить, что мы разрабатывали счётчик в течении 2 лет, и сначала он ничего не обрабатывал, а просто складировал данные - это мёртвый путь - мы доказали это экспериментально, если база увеличивается до 1 Мб, вы можете выкидывать весь счётчик - отчётов вы не дождётесь - хотите можете опровергнуть.

>Как же это решить? Ну во превых действительно жизненно
>необходимо разделить сбор и обработку информации. Размеры
>загружаемого посетителем скрипта сокращаются уже вдвое.
>Далее, следует уменьшить количество таблиц в БД.
Понимаете это ведь всё было в первых версиях - вы же ведь в отличие от нас не проводили замеров времени и экспериментов? Распределённая 1 задача среди 1000 посетителей не вызывает у них никаких задержек, а вот 1000 умноженная на 0.1 секунды - это уже больше минуты...

>При переносе обработки во внешнюю конструкцию и удалении
>лишних таблиц, мы получаем экономию 60%-80% места базы
>данных и 4-12 секунд экономии в загрузке страниц. В случае
>же того счастливца с 2ГБ-ной базой мы получаем экономию
>~1,5ГБ места и ускорение загрузки раз в 10, а то и больше...
>Неплохо, правда?
А вы это попробуйте сделать... и быстро убедитесь, что у нас браузеры и операционные системы храняться в 1 байте, а USER_AGENT у вас будет занимать десятки байт и длительность операций и объём возрастают так, что дух захватывает - я это видел собственными глазами - мы же хранили USER_AGENT-ы - избавились от них лишь потому, что не было сил дальше содеражать все эти сотни мегабайт информации - USER_AGENT были сжаты в ENUM.

>Итого, вынося обработчик собранной информации в отдельный
>файл (и вызывая его по мере необходимости, например при
>выдаче статистики админу) Мы значительно увеличиваем шансы
>того, что посетитель составит лучшее мнение о Вашем проекте.
Это голословно, у нас даже когда база была 1 таблица была в районе 400 Мб - это не отражалось на скорости работы сайта, теперь, когда мы храним данные только за сутки - это вообще практически не реально. А те операции которые производятся перед помещением в таблицы - это такая ерунда по сравнению с самими SQL-запросами - вот если можно было бы уменьшить число SQL-запросов - это да значительно бы сокращало время.

>Правда слегка замедляется получение и просмотр
>статистических данных нами, но нам-то спешить некуда (по
>большому счету и в разумных пределах), мы-то загрузки
>страницы дождемся в любом разе...
Я тоже так думал, правда через год надоедает... а когда внешние счётчики просто летают - начинаешь чесать репу и задумываться над тем, что что-то идёт не так.

>Повторюсь еще раз, но данный текст пишется не для того, что
>бы охаять создателей PowerCounter'а, глубоко мной уважаемых,
>а наоборот, помочь в улучшении данного продукта. Давайте
>придерживаться здоровой критики и самокритики (если кто-то
>найдет ошибки или недочеты в данном решении проблемы, то с
>удовольствием выслушаю их от Вас).
Критика принята, будем делать count.php более компактным, но хранить строки - это не выход.

>Помните, дурак не тот, кто совершает ошибки, а тот, кто на
>них не учится и повторяет их...
Это вы к чему :)))

>Кроме идентификации посетителя по REMOTE_ADDR, можно
>добавить его идентификацию по REMOTE_HOST и REMOTE_PORT. О
>том, для чего это нужно, я постил в
>http://www.softtime.ru/forum/read.php?id_forum=2&id_theme=11878
Подумаем, сейчас когда происходит архивирование - на такие добавления нужно время.

Аргумент про два года звучит не очень убедительно...:-)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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