Профилирование метода Do (основное время выполнения) с помощью Spring AOP

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

Я знаю, это профилировщик 101. Я использую профилировщик TPTP. Но мне это не нравится. Честно говоря, я просто не понимаю, как это работает, и когда я профилирую свое приложение (запускаю сервер в режиме профилирования), требуется вечность, чтобы ничего не делать. (ну, не то, что я ожидаю: простой вывод времени выполнения)

поэтому я делаю профилирование себя с системным временем (добавьте строку в начале и в конце методов). Все не так плохо.

мой вопрос: я хочу измерить системное время до и после вызова метода с помощью Spring AOP, можете ли вы дать мне направление? Это хорошая / плохая идея ? База кода довольно большая, и у нас не так много модульных тестов, не может ли это быть "опасно" ?

Я не прошу код, я думаю, что могу сделать это сам с такой ссылкой : http://static.springsource.org/spring/docs/2.5.x/reference/aop.html

но если у вас есть хороший учебник ( никогда не делал AOP раньше, просто знаю концепцию), я беру его.

4 ответов


есть встроенная поддержка для этого весной.

Я попытался найти учебник, но удивительно, что я не нашел его, поэтому я попытаюсь объяснить это здесь. (EDIT: я добавил этот пример в свой блог здесь)

В основном вам нужно расширить класс CustomizableTraceInterceptor следующим образом:

public class MyTraceInterceptor extends CustomizableTraceInterceptor {

  protected void writeToLog(Log logger, String message, Throwable ex) {
    if (ex != null) {
        logger.info(message, ex);
    } else {
        logger.info(message);
    }
  }


  protected boolean isInterceptorEnabled(MethodInvocation invocation, Log logger) {
    return true;
  }
}

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

Теперь вам нужен XML, чтобы выбрать, какие бобы вы собираетесь обернуть:

    <!-- Tracing -->

<bean name="traceInterceptor" class="MyTraceInterceptor" dependency-check="none">

    <property name="enterMessage" value="ENTER: $[targetClassShortName].$[methodName]($[arguments])"/>

    <property name="exitMessage"

              value="EXIT: $[targetClassShortName].$[methodName]() : $[invocationTime]ms : $[returnValue]"/>

</bean>

<bean class="org.springframework.aop.framework.autoproxy.BeanNameAutoProxyCreator" dependency-check="none">

    <property name="beanNames" value="*RequestListener,*Notifier"/>

    <property name="proxyTargetClass" value="true"/>

    <property name="interceptorNames">

        <list>

            <value>traceInterceptor</value>

        </list>

    </property>

    <property name="order" value="2"/>

</bean>

В основном вы определяете бобы, которые хотите обернуть подстановочным знаком в " beanNames "и" order " управляет упорядочением упаковки - если у вас нет других классов AOP, вы можете удалить его. Вы также можете изменить формат вывода, если измените enterMessage и exitMessage свойства.

этого должно быть достаточно, чтобы вы начали. Если вам нужны разъяснения, не стесняйтесь спрашивать.


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

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


рядом с VisualVM, который Ник упомянул еще один хороший (и бесплатный для разработки) кусок программного обеспечения Оракул Виртуальная Машина JRockit Управления Полетами. Его Консоль Управления обладает способностью к простым вызовам профиля некоторых методов (плюс есть больше вариантов профилирования и определенно быстрее, чем TPTP).

Как и при измерении системного времени до / после вызовов метода: в основном он работает, но имеет некоторые незначительные "недостатки" (например, фоновые приложения могут " изменять результат.)

лично я бы сначала пошел с VisualVM или JRockit Mission Control.


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

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

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

Если есть отходы, это будет быстро найти его. Причина проста: если какой-то процент (скажем, 40%) тратится впустую, то этот процент образцов (в среднем) покажет вам, как именно он тратится впустую.

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

добавлено: вы можете подумать, что большая часть, такая как 40%, нереалистична, потому что вы не можете себе это представить, но это вполне возможно.