Новая тема   Ответить

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

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

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

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

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


   $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);


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

 Sven
gimcnuk писал:

спасибо

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

 ibiz
CABMIT писал:

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

 iRoot
Реализовывать это на файлах очень порочная идея, никакие 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

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

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

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

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

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

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

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

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

 iRoot

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

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

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

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

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

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

 RA Optimus



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