Не могу увидеть мои собственные методы приложения в Java VisualVM

Question

Я пытаюсь профилировать свое Java-приложение, просто чтобы выяснить методы, в которых тратится больше всего времени. Учитывая плохую реакцию на TPTP, я решил попробовать Java VisualVM.

Все это казалось довольно простым в использовании - за исключением того, что я не могу извлечь из этого ничего последовательного или полезного.

Я не вижу ничего, связанного с МОИМ СОБСТВЕННЫМ кодом - все, что я получаю, это целая куча вызовов таких вещей, как java. * Методы.

Я пытался ограничить инструментарий только моими собственными пакетами, что, похоже, сокращает количество инструментов, но, тем не менее, я никогда не вижу свой собственный.

Каждый раз, когда я бегу, я получаю различное количество инструментов, от 10 до 1000 лет. Я пытался заснуть в начале своего приложения, чтобы убедиться, что я запускаю VisualVM до того, как мое приложение начинает делать что-нибудь интересное, чтобы убедиться, что оно профилируется, когда запускаются интересные вещи.

Есть ли что-то, что я должен сделать, чтобы мои классы были проинструктированы? Есть ли проблемы со временем? .. как, должны ждать загрузки классов и т. д.? Я также попытался дважды запустить внутреннюю часть кода, чтобы убедиться, что весь код выполняется ...

Я просто запускаю приложение с основным из Eclipse. Я попытался использовать интеграцию Eclipse, чтобы VisualVM запускался при запуске приложения - результаты совпадают. Я также пытался экспортировать приложение как работающее приложение и запускать его автономно из командной строки, а не через Eclipse - тот же результат.

Мое приложение не является долго работающим веб-приложением и т. Д. - просто основным, которое вызывает некоторые другие мои собственные классы для некоторой обработки, а затем закрывается.

Буду благодарен за любые советы о том, что я могу делать неправильно! :)

Спасибо!

Answer 1

Я тоже борюсь с VisualVM, что обидно, потому что его пользовательский интерфейс фантастический, а его профилирование выводит в ужас.Вы можете показаться, что мой вопрос здесь.

Java VisualVM дает странные результаты для профилирования процессора - кто-нибудь еще сталкивался с этим?

Я могу рассказать вам пару странных вещейчто я узнал о VisualVM и о способах его профилирования.

Кажется, VisualVM рассчитывает общее время, проведенное внутри метода (время настенных часов).У меня есть поток в моем приложении, который запускает ряд других потоков, а затем сразу же блокирует ожидание сообщения в очереди.VisualVM не будет регистрировать этот метод в профилировщике, пока один из других потоков не отправит сообщение, которого ожидал первый поток (когда приложение завершается).Внезапно вызов метода блокировки преобладает над выходом профилирования и записывается как занимающий более 80% времени приложения.

Другие профилировщики, такие как JProfiler и тот, который используется Azul, не считают заблокированный поток как требующий времени для профилировщика.Это означает, что методы блокировки, которые, вероятно, не интересны (зависят от ситуации) для профилирования производительности, затеняют ваше представление о том коде, который потребляет ваше процессорное время.

Когда я выполняю свое профилирование, я получаю

sun.rmi.transport.tcp.TCPTransport $ ConnectionHandler.run ()

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

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

Не очень полезный ответ.Решение, которое я вижу сейчас, состоит в том, чтобы заплатить за JProfiler - VisualVM просто не выглядит заслуживающим доверия для этой задачи.

Answer 2

вы можете взглянуть на Appdynamics lite, у него есть приятные функции, такие как обнаружение бизнес-транзакций, которое может сэмплировать все вызовы, сделанные к определенному методу в вашем коде.

Облегченная версия имеет множество ограничений, таких как максимальная выборка 10 минут и максимальное обнаружение 30 бизнес-транзакций.

Было бы неплохо иметь бесплатные инструменты, которые делают то же самое

Answer 3

Я предполагаю, что это не просто академический вопрос - вы хотели бы посмотреть, сможете ли вы заставить приложение работать быстрее.Я полагаю, вы также не будете возражать, думая немного «из коробки».Есть много популярных идей о производительности, которые на самом деле довольно размыты.

Например, вы говорите, что ищете «методы, в которых тратится большинство времени».Если под этим вы подразумеваете «собственное время» (фактически счетчик программ в методе), то, вероятно, очень мало, если у вас нет интенсивных циклов.Обычно методы тратят время, вызывая другие методы, иногда выполняя операции ввода-вывода.

Другая нечеткая идея заключается в том, что измерение времени метода или подсчет количества вызовов может очень сильно рассказать вам о узких местах.Узкие места - это конкретные строки кода, а не методы, поэтому даже если вы знаете, где искать, вы все равно играете в детективы.

Так что это лишь некоторые из нечетких идей. Вот еще куча. Позвольте мне предложить, как должен подумать об этом, и как это приводит к результатам.

Когда вы в конечном итоге что-то исправите, это уменьшитвремя выполнения на несколько процентов, например (выберите число) 30%, верно?(В противном случае вы ничего не исправили.) Хорошо, в течение этих 30% он делал что-то, что ему не нужно было делать, потому что позже вы избавились от этого.Итак, вам не нужно измерять.Вам нужно нужно выяснить что он делает в это время, чтобы вы знали, от чего избавиться.

Очень простой способ - это«Пауза» это 10 (или некоторое количество) раз наугад.Понять, что он делает и почему, посмотрев на стек вызовов и, возможно, некоторые данные.Примерно в 3 из этих случаев вы увидите, что он делает что-то, от чего вы могли бы избавиться.

Вы узнаете приблизительно , сколько это сэкономит, увидев, какой процент образцов показываетЭто. Приблизительно достаточно хорошо. Вы можете легко увидеть, сколько именно сэкономлено времени, остановив его до и после.

Тогда не останавливайтесь.Вы сделали приложение быстрее.Сделайте это снова и сделайте это еще быстрее.Рано или поздно вы попадаете в точку, когда вы не можете сделать это быстрее, но, вероятно, это более чем за один шаг.