Czy profilowanie metod (podstawowy czas wykonania) Ze sprężyną AOP

Question

Szukam funkcji lub oprogramowania, które pozwoli mi łatwo profilować czas wykonywania mojej metody i wybrać profil do wyświetlenia według filtru pakietów.

Wiem, to profiler 101. Używam profilera TPTP. Ale nie jestem z tego zadowolony. Szczerze mówiąc po prostu nie rozumiem, jak to działa, a kiedy profiluję moją aplikację (uruchamiam serwer w trybie profilowania), nie ma na nic czasu. (cóż, nie to, czego się spodziewam: proste wyjście czasu wykonania)

Wykonuję profilowanie z czasem systemowym (dodam linię na początku i na końcu metod). Nie jest tak źle.

Moje pytanie brzmi: chcę zmierzyć czas systemowy przed i po wywołaniu metody w Spring AOP, czy możesz podać mi kierunek? To dobry/zły pomysł? Baza kodu jest dość duża i nie mamy wielu testów jednostkowych, czy nie może być ona "niebezpieczna"?

Nie pytam o kod, myślę, że mogę zrobić to sam z takim linkiem: http://static.springsource.org/spring/docs/2.5.x/reference/aop.html

Ale jeśli masz ładny samouczek (nigdy nie sporządzono AOP przed, wystarczy wiedzieć koncepcji) Biorę to.

Answer 1

Jest na to wsparcie na wiosnę.

Próbowałem szukać samouczka, ale zaskakująco go nie znalazłem, więc spróbuję to wyjaśnić. (EDIT: I dodaje ten przykład do mojego blogu here)

zasadzie to, co potrzebne jest, aby rozszerzyć klasę CustomizableTraceInterceptor tak:

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; 
    } 
} 

Podklasa ta nie owija wokół informacji fasola i wyjść metoda połączenia, w tym parametrów, zwraca wartości i czas wykonania do dziennika. Zmieniając metodę writeToLog(), kontrolujesz, gdzie chcesz wyprowadzać dane i jakie jest ich znaczenie.

Teraz trzeba trochę XML rzeczywiście wybrać fasola masz zamiar zawinąć:

<!-- 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> 

Zasadniczo można zdefiniować fasoli chcesz zawinąć asterisk w „beanNames” i „porządku” kontroluje kolejność zawijania - jeśli nie masz innych klas AOP, możesz go usunąć. Możesz również zmienić format danych wyjściowych, jeśli zmienisz właściwości enterMessage i exitMessage.

To powinno wystarczyć do rozpoczęcia pracy. Jeśli potrzebujesz wyjaśnienia, nie wahaj się zapytać.

Answer 2

Podejście AOP będzie działało, ale w zależności od tego, w jaki sposób zamierzasz rejestrować informacje, samo może wpłynąć na wydajność - po prostu pamiętaj o tym, upewnij się, że rejestrowanie jest wydajne, jak to możliwe, i upewnij się, że błąd w obsłudze on-point w twoim aspekcie.

Możesz również chcieć wyglądać jak Visual VM - Byłem pod wrażeniem tego narzędzia, jest łatwe w użyciu i było w stanie dostarczyć mi tylko tych informacji, których potrzebowałem, kiedy ostatnio go używałem.

Answer 3

Poza VisualVM, o którym Nick wspomniał o innym dobrym (i wolnym do rozwoju) oprogramowaniu, jest Oracle JRockit Mission Control. Jego konsola zarządzania has the ability do prostych wywołań profili niektórych metod (plus jest więcej opcji profilowania i zdecydowanie szybciej niż TPTP).

Podobnie jak w przypadku systemu pomiarowego czas przed/po wywołaniach metod: w zasadzie działa, ale ma pewne drobne "wady" (na przykład aplikacje działające w tle mogą "zmienić" wynik).

Osobiście osobiście poleciłbym najpierw za pomocą VisualVM lub JRockit Mission Control.

Answer 4

Problem z "profilerem 101" polega na tym, że zawiera wiele pomysłów, których uzasadnienie jest bardziej kwestią popularności niż rozsądnego myślenia.

Największy taki pomysł polega na tym, że najlepszym sposobem na znalezienie problemów z wydajnością jest mierzenie wydajności.

To jest myślenie odgórne, a to tak, jakby próbować znaleźć odpady w rządzie, patrząc na budżet każdego departamentu. Alternatywą jest podejście oddolne, takie jak wybranie kilku losowych jednostek pieniędzy lub czasu oraz (najważniejsze) określenie, w którym każdy z nich jest wydawany.

Jeśli są odpady, szybko to znajdziesz. Powód jest prosty, jeśli niektóre procenty (np. 40%) są marnowane, wtedy ten procent próbek (średnio) pokaże dokładnie, jak jest marnowany.

This is the language-agnostic method I use.

DODANO: Możesz myśleć, duża część jak 40% jest nierealne, ponieważ nie można sobie wyobrazić, but it's entirely possible.