Счетчик посещаемости

← →
Kerk © (2009-12-16 03:26) [0]

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

Пока единственное, что я придумал - анализировать логи веб-сервера скриптом, запускаемым по крону раз в 15 минут, и складывать информацию в базу. Но как-то оно не очень изящно.

Еще какие-нибудь варианты есть?

← →
KilkennyCat © (2009-12-16 03:51) [1]

> хотя сам хостинг полноценный

должен вести статистику самостоятельно. PeterHOST, например, ведет и дает доступ.

← →
KilkennyCat © (2009-12-16 03:52) [2]

а, я пропустил слова про запись в БД....

← →
Eraser © (2009-12-16 04:02) [3]

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

← →
Kerk © (2009-12-16 04:13) [4]

> Eraser © (16.12.09 04:02) [3]

Да, хорошая мысль. Вот чего нашел:
http://logtomysql.sourceforge.net/readme.html
http://bitbrook.de/software/mod_log_mysql/

Вот если бы что-то такое, но для nginx, я был бы совсем счастлив. Такой вариант для меня был бы идеален.

← →
brother © (2009-12-16 05:56) [5]

сайт на php&? может всеж добавить код во все страницы можно?

← →
Kerk © (2009-12-16 06:04) [6]

> brother © (16.12.09 05:56) [5]

"сайт статический" (с) [0]

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

← →
Kerk © (2009-12-16 06:43) [7]

Еще вариант, уже подходящий для nginx:
tail -f /path/to/nginx.log | <писатель в mysql>
http://www.freebsd.org.ua/man/tail.1.html

Ищем дальше :)

← →
@!!ex © (2009-12-16 10:29) [8]

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

← →
Kerk © (2009-12-16 16:38) [9]

> @!!ex © (16.12.09 10:29) [8]

Не надежный вариант.
1) У юзера могут быть выключены картинки или просто картинка может не загрузиться по каким-то причинам
2) Если в браузере отключен referer, то я вообще не узнаю откуда картинка вызвана

← →
Anatoly Podgoretsky © (2009-12-16 16:44) [10]

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

← →
Kerk © (2009-12-16 17:15) [11]

> Anatoly Podgoretsky © (16.12.09 16:44) [10]

См [9]

← →
Anatoly Podgoretsky © (2009-12-16 19:54) [12]

"например"
Я вообще предлагаю делать динамическую страницу, на сервере будет происходить запись в БД при обращение и далее выдаваться текст страницы.

← →
Kerk © (2009-12-16 20:09) [13]

> Anatoly Podgoretsky © (16.12.09 19:54) [12]

динамическую страницу я не хочу

← →
Nucer (2009-12-16 20:20) [14]

Можно написать PHP скрипт со счетчиком и через mod_rewrite (htaccess) перенаправлять на него запросы. Грубо говоря:

.htaccess
Options +FollowSymLinks RewriteEngine On RewriteRule \.html$ gate.php

gate.php
<?php $r = $_SERVER["REQUEST_URI"]; $r = preg_replace("(^/+)", "", $r); if ($r == "") $r = "index.html"; else if (!preg_match("/^[a-z]+\.html$/", $r)) die("Bad request!"); if (!file_exists($r)) die("File not found!"); // Counter readfile($r); ?>

← →
Kerk © (2009-12-16 20:28) [15]

> Nucer (16.12.09 20:20) [14]

динамическую страницу я не хочу

← →
Nucer (2009-12-16 20:32) [16]

> динамическую страницу я не хочу

В смысле? Тут динамики минимум (нагрузка минимальная). Скрипт только считает, а потом выводит в поток содержимое файла в чистом виде.

http://php.su/functions/?f=readfile&choice=info

Редактировать старые страницы не надо, всего лишь скопировать на хостинг 2 файла.

Само собой регулярное выражение написать свое (сейчас если файл лежит не в корне или имя содержит что-либо кроме латинских букв, то будет выведено сообщение "Bad request!").

← →
Kerk © (2009-12-16 20:38) [17]

> Nucer (16.12.09 20:32) [16]
>
> > динамическую страницу я не хочу
>
> В смысле?

В прямом. Динамические страницы я не хочу.

← →
Nucer (2009-12-16 20:48) [18]

Чем отличаются динамические страницы от статических? Если тот же самый код из [14] будет написан не на PHP, а на СИ (и будет подключен каким-то образом к httpd, nginx или к чему-нибудь еще), это уже будет статическая страница?

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

← →
DVM © (2009-12-16 20:54) [19]

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

← →
Kerk © (2009-12-16 20:56) [20]

> Nucer (16.12.09 20:48) [18]

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

На текущий момент самый хороший вариант, на мой взгляд, описан в [7]. Может быть, что-то еще удастся придумать.

← →
Омлет © (2009-12-16 21:09) [21]

> [17] Kerk © (16.12.09 20:38)

И где там динаамические страницы? Человек дело говорит.

← →
Kerk © (2009-12-16 21:11) [22]

> Омлет © (16.12.09 21:09) [21]

Я рассказал, что мне нужно. Рассказал уже не один раз тут. Если всем пофиг, то ветку можно закрывать.

← →
Медвежонок Пятачок © (2009-12-16 21:39) [23]

я хочу, чтобы веб-сервер занимался своей основной обязанностью - раздавал контент и все

клиентские скрипты на странице допустимы?

← →
Anatoly Podgoretsky © (2009-12-16 21:45) [24]

> Kerk (16.12.2009 20:09:13) [13]

Тогда просто - "Счетчик = 123"
Все остальное это уже динамическая страница.

← →
@!!ex © (2009-12-16 21:47) [25]

> [24] Anatoly Podgoretsky © (16.12.09 21:45)

+100

← →
Anatoly Podgoretsky © (2009-12-16 21:59) [26]

Для формирования "динамических" страниц удобно использовать SSI - текст страницы не требуется изменять, в рантайм подставляется нужное значение. Я использовал такое на Линуксе (Апач) со скриптом сначала на Перле, а потом написал на Паскале, для повышения быстродействия.

← →
Piter © (2009-12-16 22:02) [27]

странно сформулированные требования, конечно.

Я так и не понял, сервер работает на nginx, на апаче, или на ихней связке? Как я догадываюсь - последнее.

И также как я понимаю, этим и обосновано стремление к статике, чтобы именно nginx отдавал контент не нагружая медленный apache?

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

Другое дело, если большинство контента отдается nginx"ом и до апача не доходит. Наверное, надо смотреть в сторону анализаторов лога nginx"а, такие наверняка есть.

Еще вариант - в текст страниц внедрить скрипт любого готового счетчика (li, spylog или подобный), получишь готовую статистику. Она, конечно, отличается от реальной статистики, но это уже паранойя, в конце концов можно раздобыть поправочные коэффициенты. У нас например счетчики показывали порядка 22 тысяч посетителей, в то время как по логам апача выходило тысяч 25. Не так уж принципиально.

И конечно крайне удивительно пренебрежение динамикой, даже сложно представить себе такой сайт. Уже готовые сверстанные HTML страницы? Но это же ужасно.. Вот тот же счетчик надо будет внедрить - значит, тебе придется переделывать каждую страницу. Любое телодвижение по смене фейса сайта - и это ппц головная боль, пропорционально растущая с увеличением контента сайта.
Это, конечно, отдельный разговор, но такая фанатское стремление к статике... непонятно... Сайт такой высоконагруженный? Обычно PHP как таковой то летает, проблемы с базой данных начинаются...
В конце концов посмотри на примитивно эффективную технологию memcached (которую для ЛЖ изобрели по началу)... Да много чего можно придумать...
В 2009 году ориентироваться на статику... ну вообще необъяснимо. Все таки ты подумал бы в этом направлении.

← →
McSimm © (2009-12-16 22:08) [28]

> И где там динаамические страницы? Человек дело говорит.

это динамические страницы в полном смысле.
начать с того, что отдавая статические файлы сервер самостоятельно отслеживает и отрабатывает 304

> начать с того, что отдавая статические файлы сервер самостоятельно
> отслеживает и отрабатывает 304

а так же не менее нужное 206 :)

> Piter © (16.12.09 22:02) [27]
> Вообще, самое быстрое решение проблемы - использование готового
> анализатора логов. Их для апача написано вагон и маленькая
> тележка. Скармливаешь ему лог от апача, он все это распарсивает
> в базу (самый медленный процесс), далее можешь смотреть
> всякие графики и прочее, ну по крайней мере так работает
> большинство анализаторов.

Все это здорово, но мне нужно решение приближенное к realtime, а не по итогам дня. Допустима задержка в несколько минут, не более. Потому рассматриваю вариант [7], вариант [4] хорош сам по себе, но к nginx его не прикрутить из-за особенностей работы nginx. Если есть еще варианты, я буду рад, если нет... ну судьба значит использовать [7].

> Еще вариант - в текст страниц внедрить скрипт любого готового
> счетчика (li, spylog или подобный), получишь готовую статистику.
> Она, конечно, отличается от реальной статистики, но это
> уже паранойя, в конце концов можно раздобыть поправочные
> коэффициенты. У нас например счетчики показывали порядка
> 22 тысяч посетителей, в то время как по логам апача выходило
> тысяч 25. Не так уж принципиально.

Мне надо в базу, чтобы обрабатывать самому. Дело не в паранойе, а в задаче. Иначе бы я сразу поставил Google Analytics и про проблему забыл.

> И конечно крайне удивительно пренебрежение динамикой, даже
> сложно представить себе такой сайт. Уже готовые сверстанные
> HTML страницы? Но это же ужасно.. Вот тот же счетчик надо
> будет внедрить - значит, тебе придется переделывать каждую
> страницу. Любое телодвижение по смене фейса сайта - и это
> ппц головная боль, пропорционально растущая с увеличением
> контента сайта.

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

> Обычно PHP как таковой то летает, проблемы с базой данных
> начинаются...

Дык а куда мне там PHP без базы данных? Мне как раз придется на каждый запрос соединение с БД создавать, если делать так, как говорят те, кто предлагает переходить на динамику. Это в том случае, если мне удастся запускать все это из nginx через FastCGI (я с ним на "Вы", мягко говоря), иначе кроме создания соединения к БД утяжелять процесс будет обращение к апачу.

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

← →
Nucer (2009-12-16 23:14) [32]

> начать с того, что отдавая статические файлы сервер самостоятельно
> отслеживает и отрабатывает 304

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

Экономить на PHP = экономить на спичках. Если не нравятся постоянные соединения с MySQL (которые опять же отнимают не так много времени) то, как и писали выше, можно использовать memcached. А можно делать и еще хитрее (зависит от условий, от сайта и т.д.). Например: if random(10) = 0 then inc(Counter, 10).

Если уж анализировать логи, то в nginx они опять же очень легко настраиваются (когда их писать, когда не писать, в каком формате писать и т.д. с регулярными выражениями и прочими удобствами).

Kerk © (16.12.09 22:23) [30]
но это нужно далеко не всем, потому основная нагрузка приходится на статику. Если ее превратить в динамику, будет не эстетично в конце концов.

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

Kerk © (16.12.09 22:23) [30]
Мне как раз придется на каждый запрос соединение с БД создавать, если делать так, как говорят те, кто предлагает переходить на динамику

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

Да блин если хостер нормальный и оптимально делать - то PHP летает, а если хостер лажовый, так у тебя и статика через рад будет отдаваться... Вообще че то все надуманно как-будто...

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

на десятки и сотни тысяч онлайна коннект к мусклу не создается для каждого, не всегда даже апач берут (кол-во соединений вроде у него 255), разделение на отдачу статики (ngix обычно), и сам код хайлода несколько отличается от среднестатического сайта

десятки тысяч одновременных коннектов это вообще уровень какого-то амазона уже, вы что...

Я имел в виду десятки, сотни тысяч посетителей в сутки. Это уже очень крупный сайт.

10-20 тысяч транзакций в секунду - это нагрузка Skype с 300 миллионами абонентов и 10-20 миллионов онлайн.

А сотни тысяч онлайн коннектов (скорее всего и десяток тысяч) мускул просто не перенесет.
Больше 65 тысяч коннектов нельзя сделать просто по граничениям TCP/IP протокола...

так что antonn назвал абсолютно нереальные цифры, тем более в контексте сайта Kerk"а ))

Не, тысячи одновременных коннектов - это не ко мне, конечно. Тут речь скорее о цифрах в районе от 0 до 10 в секунду в пиковые моменты.

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

У меня железо несколько иное :)

> Ты же сам писал на PHP, что сайты так дико тормозят?
>
> Да блин если хостер нормальный и оптимально делать - то
> PHP летает

Да причем тут само PHP? Если посмотреть в "top", можно увидеть, что мускул (у меня по крайней мере) жрет процессорного времени в разы больше, чем все остальные процессы на сервере вместе взятые.

> Больше 65 тысяч коннектов нельзя сделать просто по граничениям
> TCP/IP протокола...
>
> так что antonn назвал абсолютно нереальные цифры, тем более
> в контексте сайта Kerk"а ))

я не про сайт Керка, и я не говорил про одинокий комп, в который все ломятся :)

Kerk © (17.12.09 15:26) [38]
У меня железо несколько иное :)

я так понимаю все это твой хваленный VDS, результатом выходит оптимизация сайта в виде статики?!
Не знаю, дело твое несомненно, но на мой взгляд гораздо комфортнее доплатить $10-$50 (или сколько там нужно) в месяц и не парится. Это просто эффективнее, чем в 21-ом веке париться насчет оптимизации сайта в сторону статики, это просто ахринеть. Уровень narod.ru какой-то.

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

Счетчик посещаемости Найти похожие ветки