LINUX.ORG.RU

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


0

1

Совет нужен.

Задача простая — учёт загрузки Web-системы. Пишем в хранилище имя класса выводимого объекта, время генерации, IP клиента и немного другой информации.

Нужно при каждом запросе проверять суммарное время работы клиента и при превышении лимита возвращать 503-ю ошибку.

Также должна быть возможность посмотреть какие классы грузят систему больше всего, какие пользователи, комбинированную нагрузку (класс+пользователь).

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

Первое, что приходит в голову — например, хранить суммарное время работы клиента и классов в чём-то типа key-value, в хеше. В том же Redis. Но тогда замучаешься потом выводить топ по загрузке.

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

Какая-нибудь БД, проще и легче MySQL? Ибо логика предельно простая.

А, да — всё это на PHP, т.е. биндинги рассматриваемых систем приветствуются.

Есть мысли на чём можно тут сэкономить?
~~~

★★★★★

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

оно?

anonymous ()

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

anonymous ()
Ответ на: комментарий от anonymous

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

оно?

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

anonymous ()
Ответ на: комментарий от RR

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

KRoN73 ★★★★★ ()
Ответ на: комментарий от drakmail

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

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

KRoN73 ★★★★★ ()

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

boombick ★★★★★ ()

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

Eddy_Em ☆☆☆☆☆ ()

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

iBliss ()
Ответ на: комментарий от Eddy_Em

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

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

KRoN73 ★★★★★ ()
Ответ на: комментарий от boombick

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

KRoN73 ★★★★★ ()

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

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

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

soomrack ★★★ ()
Ответ на: комментарий от soomrack

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

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

basp ()
Ответ на: комментарий от soomrack

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

true_admin ★★★★★ ()

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

Nagwal ★★★★ ()
Ответ на: комментарий от Nagwal

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

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

KRoN73 ★★★★★ ()
Ответ на: комментарий от KRoN73

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

Nagwal ★★★★ ()
Ответ на: комментарий от dizza

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

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

KRoN73 ★★★★★ ()
Ответ на: комментарий от Nagwal

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



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

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

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

KRoN73 ★★★★★ ()
Ответ на: комментарий от KRoN73

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

dizza ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.