Профилировщики Java, которые отображают статистику запросов и поток программ

Question

Я ищу профилировщики, которые поддерживают статистику профилирования по запросу, в идеале вдоль потока программ (а не обычного стека вызовов потоков). Таким образом, в основном стек вызовов профилировщика + представление последовательных вызовов для каждого отдельного запроса, что-то вроде этого:

doGet                 100ms
+ doFilter             95ms
  + doFilter2          90ms
    + validateValues   20ms
    + calculateX       40ms
      + calc1          10ms
      + calc2          30ms
    + renderResponse   30ms

Какие профили классов / методов настроены каким-либо образом, для профилировщика трассировки, который обрабатывает каждый вызов метода, это, конечно, невозможно использовать.

Я знаю и использовал dynaTrace, его функцию «PurePath» (http://www.dynatrace.com/en/architecture-tame-complexity-with-purepath.aspx) поддерживает это, но я ищу инструменты, которые можно использовать в небольших проектах и ​​которые требуют меньших начальных инвестиций и настройки.

Поддерживает ли это какой-либо "классический" профилировщик (YourKit и т. Д.), И я пропустил эту функцию?

Приложение: Чтобы представить некоторую предысторию: Основная цель - получить статистику для мониторинга и анализа системы в производстве. Прежде всего, идея состоит в том, чтобы получить оперативную статистику о том, сколько времени занимают запросы, и, если время отклика увеличивается, чтобы получить данные для определенных (типов) запросов (например, JETM + x).

Статистика профилирования каждого запроса позволяет детально проанализировать, почему только некоторые запросы выполняются медленно, например, если 10% запросов занимают в десять раз больше среднего. С агрегированной статистикой это AFAIK очень трудно решить.

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

В идеале точки измерения конфигурируются и отключаются / отключаются во время работы.

Answer 1

Мой подход похож на подход Питера, но вместо использования локальных потоков и вычислений в сети я записываю в файл журнала, когда выполнение достигает интересных этапов. Кроме того, я использовал AspectJ для генерации строк журнала, что оказалось очень удобным для добавления / удаления строк журнала прихоти без необходимости изменения остальной части исходного кода.

Answer 2

Вы можете попробовать btrace , чтобы сделать выборочные измерения.Это несколько похоже на dtrace, который вы также можете использовать, если вы используете поддерживаемую платформу, Solaris, BSD, OS X.

Answer 3

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

---

Для микросекундных таймингов у меня есть значение enum для каждого этапа, а затем записывается текущее время (System.nanoTime ())когда эта стадия достигнута в массиве ThreadLocal.(Нет выделения объектов). Когда запрос завершен, запишите временные разницы в файл, например, в формате CSV.