Профилирование приложений Java EE — на что обратить внимание и какие изменения внести?

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

Например, рассмотрим метод, который работает с JAXB POJO. Метод перебирает POJO для доступа к тегу/элементу, глубоко вложенному в XML. Для этого требуется 4 слоя циклов for, чтобы добраться до элемента/тега, как показано ниже:

   List<Bundle> bundles = null;
   List<Item> items = null;
   for(Info info : data) { 
      bundles = info.getBundles();
      for(Bundle bundle : bundles) {
         items = bundle.getItems();
         //.. more loops like this till we get to the required element
       }          
    }

YourKit говорит мне, что приведенный выше код является «горячей точкой», и 80 объектов получают сбор мусора при каждом вызове метода, содержащего этот код. Приведенный выше код — это всего лишь пример, а не единственная часть, где я застреваю. В большинстве случаев я понятия не имею, что делать с информацией, предоставленной профилировщиком. Что я могу сделать, чтобы уменьшить количество временных объектов в приведенном выше коде? Существуют ли четко определенные принципы улучшения производительности приложения? На какие статистические данные следует обращать внимание при профилировании приложения и какое значение имеет каждый вид статистических данных?

Изменить. Основной целью профилирования приложения является увеличение пропускной способности и времени отклика. Текущая пропускная способность составляет всего 10 процентов от требуемой пропускной способности!


java refactoring profiling yourkit
person CKing    schedule 13.09.2012    source источник
comment
Это зависит от ваших целей производительности (время отклика? пропускная способность? использование процессора? использование памяти?)   -  person meriton    schedule 13.09.2012
comment
Меня в основном интересует пропускная способность и время отклика. У нас достаточно памяти и очень мощный процессор!   -  person CKing    schedule 13.09.2012

Ответы (3)


arrow_upward
1
arrow_downward

Сосредоточьтесь на статистике, относящейся к вашей цели производительности. Вас интересует минимальное время отклика, поэтому посмотрите, какой вклад вносит каждый метод во время отклика, и сосредоточьтесь на тех, которые вносят значительный вклад (для однопоточной обработки это просто время, прошедшее во время вызова метода, суммированное по всем вызовам этого метода). Я не уверен, что YourKit определяет как горячие точки (проверьте документы), но, вероятно, это методы с наибольшим совокупным истекшим временем, поэтому горячие точки - это хорошая вещь для просмотра. Напротив, выделение объектов не оказывает прямого влияния на время отклика и не имеет значения в вашем случае (если только вы не определили, что сборщик мусора вносит значительную долю времени процессора, чего обычно не происходит).

person meriton    schedule 13.09.2012

arrow_upward
1
arrow_downward

Я абсолютно согласен с данными ответами.

Я хотел бы добавить, что, учитывая ваш конкретный пример, вы действительно можете внести улучшения, используя xpath api для доступа к определенному местоположению в XML.

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

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

person Vitaliy    schedule 13.09.2012
comment
Мы не имеем прямого доступа к XML. JAXB распаковывает XML, полученный нашими веб-службами Apache CXF, в POJO. Мы получаем POJO в качестве параметра для конечных точек нашего веб-сервиса. Короче говоря, можно ли подключить xpath к JAXB, чтобы сгенерированные POJO содержали методы для использования XPATH? - person CKing; 13.09.2012
comment
Также обратите внимание, что обход всей модели DOM необходим во многих случаях, когда атрибуты каждого пройденного тега требуются приложению перед получением информации из листового тега. - person CKing; 13.09.2012
comment
Я не знаю метода, который позволил бы вам подключить xPath к JAXB. На самом деле это противоречило бы самой цели технологии. Извините, но я упустил из виду тот факт, что вы имеете дело с JAXB pojo и не имеете прямого доступа к Xml. Однако, как заявляли другие, создание и сбор 80 объектов ничего не значит для JVM. Что касается вашего общего вопроса, возможно, вы смотрите не в то место. Как вы пришли к выводу, что именно этот фрагмент кода занимает больше всего времени? - person Vitaliy; 13.09.2012
comment
В YourKit есть нечто, называемое Hot Spot, которое дает вам методы, которые создали большое количество временных объектов и собрали мусор. Этот конкретный метод проявил себя в горячих точках. YourKit также дает горячие точки для профилирования процессора. Тот же метод обнаружился и в горячих точках профилирования ЦП. Хотя он выполнялся всего за 20 мс! - person CKing; 14.09.2012

arrow_upward
0
arrow_downward

Способ улучшить цикл — изменить вашу схему и существенно сгладить модель, конечно, это зависит от того, можете ли вы изменить схему. Таким образом, сгенерированная Java не потребует 4 уровней зацикливания. Конечно, в конце дня вам нужно спросить себя, действительно ли код является проблемой - 80 объектов получают GCed, так? Ваше приложение работает медленно? Испытываете ли вы проблемы с памятью? Помните, что преждевременная оптимизация — корень всех зол!

Профилирование и оптимизация - сложный зверь и зависит от многих вещей (версия Java, 32-битная или 64-битная ОС и т. Д.). Кроме того, оптимизация может не всегда требовать изменений кода, например, вы можете решить проблемы, изменив политику GC на JVM — например, существуют политики GC, которые более эффективны в ситуациях, когда ваш код создает множество небольших объектов, которые необходимо GCed часто. Если бы у вас была конкретика, возможно, вам было бы легче помочь, однако ваш вопрос кажется слишком широким. На самом деле есть много книг, написанных на эту тему, которые, возможно, стоит прочитать.

person ramsinb    schedule 13.09.2012