Подсчёт кликов

подскажите, плиз, как грамотно реализовать?

задача такая - есть 150 ссылок,
in.php?id=1
in.php?id=2
..
in.php?id=150

надо считать количество кликов по ним за час, потом обнулять и заново.
сделал 150 файлов, в зависимости от ссылки из in.php открываю нужный файл и увеличиваю число там находящееся.

будет-ли это нормально работать на большом трафе? 10-20К/час?
просто не пойму как это всё будет функционировать при большом количестве одновременных запросов к файлам.
или как-то лучше по-другому сделать?

Грамотный флок поможет.

Код: [развернуть]

$fp = fopen($name, 'r+');    flock($fp, 2);    $result = fread($fp, 1024);    $result++;    fseek($fp, 0);    ftruncate($fp, 0);    fwrite($fp, $result);    flock($fp, 3);    fclose($fp);

Либо пиши в один файл, через аппенд, и раз в час считывай.

gimcnuk писал:

Грамотный флок поможет.

спасибо

20к в час - это большой траф? Шутишь? всего ~6 запросов в секунду. с файлами вариант может не прокатить в зависимости от ОС/ФС. Советую реализовать с помощью БД

CABMIT писал:

20к в час - это большой траф? Шутишь? всего ~6 запросов в секунду. с файлами вариант может не прокатить в зависимости от ОС/ФС. Советую реализовать с помощью БД

особенно если хард напрягается
+100 за БД в мемкешеде

Реализовывать это на файлах очень порочная идея, никакие flock тут не помогут, поскольку клиент может закрыть соединение в любой момент и apache просто прибьет процесс PHP, это может случиться в любом месте, например между ftruncate($fp, 0); и fwrite($fp, $result); кроме того скорость работы такого скрипта будет ниже плинтуса - 4 IO операции на запрос, в боевой ситуации на дешевом железе вы можете рассчитывать на ~ 100 IO/s и того получаем пик производительности 100/4 = 25 запросов в секунду. Конечно ОС будет объединять операции, но нужно думать головой, а не полагаться на случай.

БД тоже не самый лучший вариант для этого, оптимально использовать атомарные операции в разделяемой памяти, например при помощи расширения APC - http://www.php.net/manual/en/function.apc-inc.php
Такая операция будет атомарна, без блокировок и использования медленных ресурсов типа HDD

iRoot писал:

Реализовывать это на файлах очень порочная идея, никакие flock тут не помогут, поскольку клиент может закрыть соединение в любой момент и apache просто прибьет процесс PHP, это может случиться в любом месте, например между ftruncate($fp, 0); и fwrite($fp, $result);

Погонял на трёх хостингах с ignore_user_abort(false). Не прибивают в промежутке, файл нормально закрывается, данные держатся.

Цитата:

БД тоже не самый лучший вариант для этого, оптимально использовать атомарные операции в разделяемой памяти, например при помощи расширения APC - http://www.php.net/manual/en/function.apc-inc.php Такая операция будет атомарна, без блокировок и использования медленных ресурсов типа HDD

А расширение не везде стоит.

Sven: на всякий случай поставь ignore_user_abort(true);

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

gimcnuk писал:

Погонял на трёх хостингах с ignore_user_abort(false). Не прибивают в промежутке, файл нормально закрывается, данные держатся.

Ну за 5 минут ты ничего и не поймаешь, за более продолжительный срок глюки будут обязательно. Да и ты смотрель iostat сервера в это время? Отдавать все ресурсы сервера под +1 операции как-то слишком расточительно на мой взгляд.

gimcnuk писал:

А расширение не везде стоит.

Оно ставится везде без особых проблем, это же не на shared-хостинге 20к в час собираются гонять. Кроме того это не единственный вариант, memcached, mongodb, etc. поддерживают атомарные операции, выбор есть, что больше нравится то и ставится.

я в свое время реализовывал это с демоном
ну правда тогда и запросов было реально больше
грубо говоря скрипт через сокет просто скидывал данные о запросе демону и забывал об этом
а демон накопив опеределенный объем данных и обсчитав их внутри себя скидывал в базу

Боюсь показаться занудным, но вебсервер, обслуживая все эти клики, сам их учитывает и записывает в лог-файл. Зачем маяться учетом того, что уже учтено?

Вариант несомненно лучше чем fread/flock/fwrite с точки зрения производительности, но его тоже нужно правильно реализовать. Если логика не элементарная, то простым tail -f не обойтись, если на PHP, то тут хороший вариант предлагают
http://stackoverflow.com/questions/1102229/how-to-watch-a-file-write-in-php

можно создать рамдиск
раскидать клики по нескольким файлам на рам, чтобы не было локов
и по крону посчитать

быстро и эффективно

20 тыщ - это копейки. не вижу смысла изобретать велосипед и ставить лишние тулзы

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

Ошибаетесь, APC - это в первую очередь кеш промежуточного кода, за счет этого PHP не нужно каждый раз парсить php-файлы, это дает значительное ускорение работы особенно когда кода много, по моим тестам от 3-ех до 10-ти раз. Дополнительно это хранилище пользовательских данных в формате ключ-значение.
Я считаю что лучшая блокировка - это ее отсуствие, с этим сложно поспорить даже SSD или RAM-диску.
Для текущей задачи оптимальное решение - атомарный инкремент значений в памяти, все остальное гораздо менее эффективно, это я и хочу сказать. Диски/файлы это все тут не годится изначально, поскольку задача - это +1 к определенному ключу, задача элементарная которая решается hash-таблицей в памяти, это один из самых базовых алгоритмов в программировании, за последние 40 лет тут ничего не изменилось. Не нужно выдумывать файлы/блокировки/RAM/SSD-диски для этого. Все элементарно просто.

видимо ошибаюсь спасибо!