Разные источники данных — разные инстансы, да.
Технически смешивать никто не мешает, но смысла в этом мало — получится «в среднем по больнице 36.6».
Поэтому у нас отдельные инстансы под FPM, CLI, nginx и еще по кластерам сервисов.
У нас это выглядит как не очень сложный скрипт, который выводит все скрипты из report_by_script_name, отсортированные по суммарному времени исполнения; имя каждого скрипта — ссылка на разбивку самого скрипта по тагам из отчета по тагу «операция»; в ней каждый таг — ссылка на разбивку по серверам из отчета по тагам «операция»+«сервер».
Таким образом, с каждым кликом попадаешь на следующий уровень детализации.
Чувствую, надо его включить с дистриб пинбы. Поговорю с народом про это…
Какая-то у вас очень странная структура с деревьями…
Есть внешние сервисы — базы, менеджеры очередей, кэши и т.п.
Не знаю где тут дерево можно применить, по-моему всё довольно плоско и просто.
'service'=>'db', 'op'=>'insert'
'service'=>'cache', 'op'=>'get'
Далее отчет по тагам сразу отвечает на вопрос сколько времени, в каком скрипте и сколько раз выполняются инсерты в базу или геты из кэша. Ничего даже делать не надо.
Специально для того, чтобы не надо было запускать сложные запросы на «сырых данных», и были сделаны обычные отчеты и отчеты по тагам. Там всё то же, но уже агрегированное по нужным полям (если не всё, то скажите мне, вместе подумаем как и что добавить).
А всё вот это копирование убивает на корню идею просмотра данных в реальном времени — в результате вы видите данные, которые были на момент последнего копирования.
Всё-таки, Pinba и XHProf решают немного разные задачи.
Пинба изначально расчитана на много серверов, которые требуют постоянного мониторинга, а не профайлинга по клику разработчика.
Ну, в нашем случае требовалось именно pre-commit review.
Вообще, на мой взгляд от пост-ревью немного толка — сам факт того, что оно «пост» расслябляет.
Оплата патчами =)
Технически смешивать никто не мешает, но смысла в этом мало — получится «в среднем по больнице 36.6».
Поэтому у нас отдельные инстансы под FPM, CLI, nginx и еще по кластерам сервисов.
Таким образом, с каждым кликом попадаешь на следующий уровень детализации.
Чувствую, надо его включить с дистриб пинбы. Поговорю с народом про это…
в realtime, 24/7 — это та задача, которую решают пинба + графики, да.
Особенно, если скрипты что-то действительно делают, а не просто echo «hello world»;.
«обращение в БД» и «получение данных из кэша» есть две разные операции, почему одна содержит другую?
Данные будут собираться, но отсылаться на сервер не будут.
Есть внешние сервисы — базы, менеджеры очередей, кэши и т.п.
Не знаю где тут дерево можно применить, по-моему всё довольно плоско и просто.
'service'=>'db', 'op'=>'insert'
'service'=>'cache', 'op'=>'get'
Далее отчет по тагам сразу отвечает на вопрос сколько времени, в каком скрипте и сколько раз выполняются инсерты в базу или геты из кэша. Ничего даже делать не надо.
А всё вот это копирование убивает на корню идею просмотра данных в реальном времени — в результате вы видите данные, которые были на момент последнего копирования.
Пинба изначально расчитана на много серверов, которые требуют постоянного мониторинга, а не профайлинга по клику разработчика.
Ну и интерфейс для управления ими впридачу.
Действительно, такая проблема есть: code.google.com/p/gerrit/issues/detail?id=1082
Я решил так — в my.cnf добавил вот эти строки:
[mysqld]
default-collation=utf8_unicode_ci
default-character-set = utf8
Перегрузил MySQL, теперь русский в комментариях работает.
Вообще, на мой взгляд от пост-ревью немного толка — сам факт того, что оно «пост» расслябляет.
twitter.com/rasmus/status/208160760302538752
это определённо не ново.
Просто не все шрифты содержат русские символы.