Система врать не будет. Если она говорит, что «libprotobuf-lite.so.7: cannot open shared object file: No such file or directory», значит этот файл системе не известен.
Я могу предположить, что надо как минимум выполнить ldconfig.
Возможно, надо еще положить эту либу туда, где ldconfig её увидит или добавить путь к ней в /etc/ld.so.conf.
В любом случае `ldd /usr/lib/mysql/plugin/libpinba_engine.so` должен успешно находить все либы.
req_time_total — суммарное время работы скрипта, SUM(req_time)
req_time_percent — суммарное время работы скрипта поделенное на суммарное время работы всех скриптов, (SUM(req_time)/time_total)*100
req_time_per_sec — суммарное время работы скрипта, поделенное на интервал времени, за который у нас собраны данные, SUM(req_time)/time_interval
скажем так, это «сколько времени тратится на этот скрипт в секунду».
по правде говоря, там эта колонка только для единообразия — во всех остальных случаях per_sec имеет бОльший смысл.
поскольку обновление отчетов по тагам — дело затратное, то предполагалось, что отчеты через некоторое время после последнего чтения могут таймаутиться и переставать обновляться.
на практике этот функционал оказался _у нас_ не востребован, в основном потому, что перегенерация отчета «с нуля» на миллионах таймеров занимает неприлично много времени.
>Насколько я помню, работа с сокетами в пхп практически напрямую работает с сишным кодом.
если говорить про ext/socket — да, там всё напрямую почти.
если говорить про PHP streams — там всё сложнее.
>В остальном я беру коэфициент 4
Непонятно почему коэффициент 4, а не 8 или не 16, например.
Если следовать вашей логике, то можно просто придумать некий коэффициент, посчитать в уме некие числа базируясь на тестах, которые проведены на ноуте, и вывести в результате что угодно.
На данный момент у вас выходит, что послать 1 UDP пакет в С/PHP занимает 0.05 секунды, я ничего не путаю? (коэффициент теперь 2, а не 4).
Это просто проверить: pastebin.com/Uxi8T0XG
Этот скрипт у меня на ноуте =) выполняется за:
real 0m3.741s
user 0m0.622s
sys 0m0.465s
Итого: около 0.00003741 сек на один вызов sendto().
Я понимаю откуда берется эта логическая связь, но вы всё-таки сами подумайте:
экстеншен шлёт UDP пакет с помощью sendto(), PHP в данном случае — это обёртка для пользователя.
Можно сколько угодно тестить TCP-коннекты в PHP, но здесь идёт речь:
1) не о PHP, а о С;
2) не о TCP, а о UDP.
>Это значит, что отправка одного юдп пакета займет около 0.1 мс. Что составляет 0.25% времени >выполнения быстрого пхп-скрипта ( 40мс ).
вы где-то пропустили логическое обоснование формулы «скорость работы TCP = скорость работы UDP * 4».
вообще, я считаю, что в таких случаях всё как раз совершенно верно: мы мониторим код, а не УРЛы.
поэтому, если у вас index.php выполняется на каждый запрос, то он и является очевидным узким местом.
но для сбора статистики и/или разделения запросов на какие-то логические/виртуальные УРЛы, можно подменить имя скрипта, как у же написали ранее.
это мониторинг проекта, на девелоперском сервере нет смысла его ставить, интересует именно текущее состояние проекта и сервисов, которые в нём используются.
UDP, конечно, не гарантирует доставку, но так быть не должно.
проверьте, что у вас буферов хватает и пакеты не теряются:
в выводе этой команды должен быть ноль: netstat -s | grep «receive errors»
Предположим, у вас есть скрипт, который шлёт на сервер N таймеров (у нас в Badoo, например, N в среднем около 30-ти).
В каждом таймере есть два-три тага (операция, сервер, результат операции или что-то около того).
В результате оверхед выходит: обработать N таймеров, сделать уникальный набор строк (для экономии на размере UDP-пакета), добавить это всё в пакет Google Protobuf и послать результат по UDP (и да, всё это на C, в экстеншене).
Сами эти операции совсем мизерные, а если принять во внимание, что таймеры в 99% случаев измеряют общение с внешними сервисами, то на фоне всего скрипта они вообще теряются.
Кроме того, все эти операции делаются во время request shutdown, когда сам скрипт уже закончил работу.
Так что я не вижу смысла даже начинать делать бенчмарки.
Я могу предположить, что надо как минимум выполнить ldconfig.
Возможно, надо еще положить эту либу туда, где ldconfig её увидит или добавить путь к ней в /etc/ld.so.conf.
В любом случае `ldd /usr/lib/mysql/plugin/libpinba_engine.so` должен успешно находить все либы.
req_time_percent — суммарное время работы скрипта поделенное на суммарное время работы всех скриптов, (SUM(req_time)/time_total)*100
req_time_per_sec — суммарное время работы скрипта, поделенное на интервал времени, за который у нас собраны данные, SUM(req_time)/time_interval
скажем так, это «сколько времени тратится на этот скрипт в секунду».
по правде говоря, там эта колонка только для единообразия — во всех остальных случаях per_sec имеет бОльший смысл.
коротко говоря, можете игнорировать её.
на практике этот функционал оказался _у нас_ не востребован, в основном потому, что перегенерация отчета «с нуля» на миллионах таймеров занимает неприлично много времени.
я помнил, что пакеты для CentOS где-то были, но найти их не смог.
если говорить про ext/socket — да, там всё напрямую почти.
если говорить про PHP streams — там всё сложнее.
>В остальном я беру коэфициент 4
Непонятно почему коэффициент 4, а не 8 или не 16, например.
Если следовать вашей логике, то можно просто придумать некий коэффициент, посчитать в уме некие числа базируясь на тестах, которые проведены на ноуте, и вывести в результате что угодно.
На данный момент у вас выходит, что послать 1 UDP пакет в С/PHP занимает 0.05 секунды, я ничего не путаю? (коэффициент теперь 2, а не 4).
Это просто проверить:
pastebin.com/Uxi8T0XG
Этот скрипт у меня на ноуте =) выполняется за:
real 0m3.741s
user 0m0.622s
sys 0m0.465s
Итого: около 0.00003741 сек на один вызов sendto().
пакеты pinba-mysql-engine и php5-pinba
действительно, надо добавить это в Вики…
Я понимаю откуда берется эта логическая связь, но вы всё-таки сами подумайте:
экстеншен шлёт UDP пакет с помощью sendto(), PHP в данном случае — это обёртка для пользователя.
Можно сколько угодно тестить TCP-коннекты в PHP, но здесь идёт речь:
1) не о PHP, а о С;
2) не о TCP, а о UDP.
>Это значит, что отправка одного юдп пакета займет около 0.1 мс. Что составляет 0.25% времени >выполнения быстрого пхп-скрипта ( 40мс ).
вы где-то пропустили логическое обоснование формулы «скорость работы TCP = скорость работы UDP * 4».
поэтому, если у вас index.php выполняется на каждый запрос, то он и является очевидным узким местом.
но для сбора статистики и/или разделения запросов на какие-то логические/виртуальные УРЛы, можно подменить имя скрипта, как у же написали ранее.
расскажите мне про жуткие варнинги подробней, плз, я посмотрю.
проверьте, что у вас буферов хватает и пакеты не теряются:
в выводе этой команды должен быть ноль: netstat -s | grep «receive errors»
В каждом таймере есть два-три тага (операция, сервер, результат операции или что-то около того).
В результате оверхед выходит: обработать N таймеров, сделать уникальный набор строк (для экономии на размере UDP-пакета), добавить это всё в пакет Google Protobuf и послать результат по UDP (и да, всё это на C, в экстеншене).
Сами эти операции совсем мизерные, а если принять во внимание, что таймеры в 99% случаев измеряют общение с внешними сервисами, то на фоне всего скрипта они вообще теряются.
Кроме того, все эти операции делаются во время request shutdown, когда сам скрипт уже закончил работу.
Так что я не вижу смысла даже начинать делать бенчмарки.