SP
условно, у тебя "сходить в сервис" - чем выполнить запрос в БД не "сходить в сервис"7
Size: a a a
2021 October 15
SP
заворачиваешь отдельные этапы в свои спаны и видишь сколько времени чего занимает
SP
как симфони профайлер если такая аналогия тебе больше нравится
ЕР
Ну это просто сложнее чем просто профайлер пускать
ЕР
Хотя и понятнее и инфы больше, да
SP
не особо, есть готовые интеграции котоорые dbal заворачивают трэйсинги и прочие газлы
SP
ты ж на проде хочешь что бы проблемы детектить
ЕР
Ну профайлер же тоже даёт свой трейс, просто он в рамках только php кода существует?
ЕР
Если профайлер не следит за стэком вызовов внутри сервиса, это уже просто какой-то лог скорости ответов получается
SP
ну вот в elastic APM ты можешь трейсы с фронта трекать и линковать это все с трейсами php и трейсами любых других вещей
SP
так "стэктрейсы" тут вообще не причем
SP
короч самый простой вариант - подними локально какой jaeger или elastic stack в докере и попробуй подключить свое приложение и поиграться. Или любой клауд солюшен. потратишь часа 4 получишь кучу опыта и скорее всего ответы на свои вопросы
ЕР
Ну тип, туда просто можно из кода кидать тайминги+контекст, и оно будет выводить флоу запроса с этими таймнгами?
SP
Stopwatch компонент в симфони видел? вот та же штука только больше фич
ЕР
SP
tracing.startSpan('App Initialization')
initializeApp()
tracing.endSpan('App Initialization')
иу тебя в туле будет сколько заняла app initialization и все запросы которые в рамках оного были. по хорошему любое "вышел из процесса наружу, в рэдисы или базу" это надо в спаны пихать
SP
там потом можешь даже агрегации искать сколько каждый такой спан занимает времени, накладывать свои ожидания вроде "вот эта штука не должна работать больше 10-ти милисекунд" и потом плевать варнинги когда "оно больше 10-ти милисекунд больше 5-ти минут подряд"
SP
если твоя цель именно мониторить производительность - то это твой вариант
ЕР
Но если надо посмотреть, почему конкретный запрос тормозил, всё-равно профайлер?