я таких не знаю, но их легко сделать
pinba работает внутри mysql (к ней можно обращаться обычными mysql запросами)
а сервисы вроде zabbix или munin умееют строить графики
То есть схема такая:
1) делаем пхп скрипт, который дергает mysql и получает нужную вам цифру и выводит в stdout
2) Прикручиваем скрипт к заббиксу или мунину для постройки графика по этому скрипту
Если интересно — могу подготовить отдельный обзор как вывести в заббикс (мунин) результаты работы pinba
Тут ещё анализируется не один скрипт, а объединенные план выполнения многих запросов к серверу
Ведь тормозное место может прятаться за логикой и не всегда проявляться
да, так и есть. 1000 запросов держит вся ферма, но они все обращаются к одной pinba. И существенного увеличения скорости работы скриптов от включения/выключения пинбы не замечалось
В случае внешних сервисов — да
Но в случае покрытия тегами нашей бизнес-логики хочется дерево
Например
<запросили баннер>
<обращение в бд>
<обращение в кеш запросов к БД>
<получение данных из кеша />
</обращение в кеш запросов к БД>
</обращение в бд>
<возврат результатов />
</запросили баннер>
Про архитектуру нашего инстанса недавно писал мой коллега — habrahabr.ru/company/wapstart/blog/146520/.
Связь непосредственно с pinba происходит по UDP, между nginx frontend и php-backend — по TCP
Если статья по ссылке не ответила на ваш вопрос — отпишитесь, я или мой коллега с удовольствием ответим
Под 1000 запросов подразумевается 1000 http запросов (это около 50 000 таймеров в секунду для пинбы)
Да, все верно, мы видим данные с последнего запуска крона, а не риалтайм.
Но мы видим данные в виде дерева, чего нет в изначальном функционале пинбы
Лично мне бы хотелось что бы у таймеров была вложеность на уровне самой пинбы (поле parent_id в таблице timertag вполне подойдет). Тогда бы не пришлось делать work-around для этого. И можно было бы строить дерево выполнения более быстро и красиво
Если бы вы работали с пространственными данными в postgres и mssql — то знали бы что postgres очень сильно уступает в производительности с пространственными данными
Чупа-чупс себе можно напечатать, че
pinba работает внутри mysql (к ней можно обращаться обычными mysql запросами)
а сервисы вроде zabbix или munin умееют строить графики
То есть схема такая:
1) делаем пхп скрипт, который дергает mysql и получает нужную вам цифру и выводит в stdout
2) Прикручиваем скрипт к заббиксу или мунину для постройки графика по этому скрипту
Если интересно — могу подготовить отдельный обзор как вывести в заббикс (мунин) результаты работы pinba
Если же серверов несколько — это становится проблематично
Ведь тормозное место может прятаться за логикой и не всегда проявляться
Но в случае покрытия тегами нашей бизнес-логики хочется дерево
Например
<запросили баннер>
<обращение в бд>
<обращение в кеш запросов к БД>
<получение данных из кеша />
</обращение в кеш запросов к БД>
</обращение в бд>
<возврат результатов />
</запросили баннер>
Связь непосредственно с pinba происходит по UDP, между nginx frontend и php-backend — по TCP
Если статья по ссылке не ответила на ваш вопрос — отпишитесь, я или мой коллега с удовольствием ответим
Под 1000 запросов подразумевается 1000 http запросов (это около 50 000 таймеров в секунду для пинбы)
Но мы видим данные в виде дерева, чего нет в изначальном функционале пинбы
Лично мне бы хотелось что бы у таймеров была вложеность на уровне самой пинбы (поле parent_id в таблице timertag вполне подойдет). Тогда бы не пришлось делать work-around для этого. И можно было бы строить дерево выполнения более быстро и красиво
Заблокировали порт, разблокировали порт
Пинбу нельзя назвать отладчиком
ЗЫ 500 Internal Server и F5 не помагает
3 месяца vs 3 года
там окошки, кнопочки и т.д. нарисованы пикселями, а не псевдографикой