Выбор бэкенда

В том же Redis. Но тогда замучаешься потом выводить топ по загрузке.
Засунуть в что-то типа MongoDB? Шило на мыло получится.

оно?

Чета мне кажется, что эта система мониторинга создает 50% нагрузки на систему...

Как варант - handlersocket

Засунуть в что-то типа MongoDB? Шило на мыло получится.

оно?

Насколько я понимаю, Mongo рулит при кластеризации и за счет отсутсвия реляционности (Join). Тут нет ни того ни другого, поэтому, простые select/update/insert шустрее не станут. А то что в Mongo тоже можно делать селекты, это и так понятно.

Рассмотрю, но смущает и отсутствие в репозиториях и высокий порог вхождения :)

MySQL с таблицами в памяти рассматривал? Довольно быстро должно получиться.

MySQL с таблицами в памяти рассматривал?

Рассматривал в первую очередь. Но у меня там текстовое поле > 255 символов (рефереры). А в памяти только VARCHAR размещать можно :-/

А ты на pinba смотрел? Это, по сути, очень хороший мониторинг со своим MySQL Engine, можно попробовать допилить и получить нужный функционал

А зачем вообще хранить такие данные на сервере? Закидывайте в local storage клиента - и дело в шляпе!

Плюсую за монго, не в пример шустрее мускля. А если нужо ещё на стороне клиента данные собрать, типа от запроса на сервере до domready - то лучше глянуть в сторону couchdb - меньше гемора с js (красиво он туды врисован)

Закидывайте в local storage клиента

Где оно у ботов? Как потом на сервере посмотреть нагрузку по типам объектов? Читайте условия задачи.

Pinba даже стояла недавно, до очередного обновления mysql. Вроде, только с точки зрения мониторинга интересна. Но тоже оценю.

Сейчас с этой задачей справляется обычная таблица mysql. Но это лишние SELECT + INSERT/UPDATE на каждое обращение. Не то, чтобы сильно сказывалось, но хочется более оптимального решения.

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

Если нужно что-то более серьезное для большой нагрузки, то сваргань на скорую руку демона. который будет выплевывать данные по UTP протоколу на другой (домашний) сервак ( http://www.sdteam.com/t3654 ).

Если нужно что-то более серьезное для большой нагрузки, то сваргань на скорую руку демона

эпичная фраза, я считаю

плюсую, нужен лёгкий коллектор который потом будет выгружать данные пачкой. А иначе оверхед приличный получается.

Писать в access.log в plain виде строчки, потом отдельным процессом их поточно парсить - не вариант? Или требование про 503 ошибку в реальном времени - критично.

Совсем в реальном — не критично.

Вот только многопоточная запись в один access.log — это блокировки и тормоза. Надо проверить, конечно, в варианте простых кешей, который я тестировал как-то, mysql оказался быстрее простых файлов. Думаю, тут может оказаться подобное.

А держать такую инфу целиком в памяти не вариант?

Ну и опять-же классическое решение (я правда не знаю, возможно ли такое в php изобразить, но на яве минут за 10 пишется) - Один поток пишет в файл, а другие ему данные скидывают через какой-нибудь BlockingQueue с большой capacity, чтобы пишущие потоки не останавливались.

А держать такую инфу целиком в памяти не вариант?

Опять блокировки нужны. Чтобы пока один процесс память меняет, другой не занимался бы тем же самым. Хотя тут это не так критично, как для файлов будет, пожалуй. Но возни много. Хотя надо прикинуть такой вариант, может, на семафорах выйдет недорого…

В PHP идеология другая. Поток только один на процесс.

…

Но мысль дельная. Можно попробовать данные gearman'у кидать (вроде бы, вызов его ненакладный, хотя не измерял), а отдельный демон будет собирать запросы, обрабатывать и пихать и в БД для статистики и сразу в key-value память для конкретных клиентов. А клиент, соответственно, прямо готовое значение для себя брать будет, проверяя, можно ли ему работать.

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

Да, на первый взгляд неплохо выходит. Хотя и громоздко немного :) Но это лучше огорода с самопальной работой с файлами или памятью.

37сигналов недавно рассказывали, как они сделали что-то похожее.

конечно все немного ruby-specific, но почитай, может пригодится: http://37signals.com/svn/posts/3091-pssst-your-rails-application-has-a-secret...

Операции доступа к памяти настолько быстры (по сравнению с обработкой http-запросов), что блокировки хоть и имеют место быть, но очереди на ресурс практически не создают, так как очень уж быстро эти очереди рассасываются. Много раз такое делал, просаживания производительности не заметил. На яве правда.