Do profiling del metodo (tempo di esecuzione di base) con Spring AOP

Question

Sto cercando una funzione o un software, che mi consentirà di definire facilmente il mio tempo di esecuzione del metodo e scegliere cosa profilo per filtro del pacchetto.

Lo so, è profiler 101. Uso il profiler TPTP. Ma non sono contento. Per essere sincero, non capisco come funziona, e quando registro la mia applicazione (avvia il server in modalità profiling), ci vuole un tempo per non fare nulla. (beh, non è quello che mi aspetto: un semplice risultato del tempo di esecuzione)

Quindi eseguo il profiling con il tempo di sistema (aggiungi una riga all'inizio e alla fine dei metodi). Non è così male.

La mia domanda è: voglio misurare il tempo di sistema prima e dopo una chiamata al metodo con Spring AOP, puoi darmi indicazioni? È una buona/cattiva idea? La base di codice è piuttosto grande e non abbiamo molti test unitari, non può essere "pericoloso"?

Non sto chiedendo per il codice, penso che posso fare io stesso con questo tipo di link: http://static.springsource.org/spring/docs/2.5.x/reference/aop.html

Ma se si dispone di un bel tutorial (mai fatto prima AOP, è sufficiente sapere il concetto), Io lo prendo.

Answer 1

C'è un supporto integrato per questo in primavera.

Ho provato a cercare un tutorial, ma sorprendentemente non ne ho trovato uno, quindi cercherò di spiegarlo qui. (EDIT: ho aggiunto questo esempio per il mio blog here)

Fondamentalmente ciò che è necessario è quello di estendere classe CustomizableTraceInterceptor come questo:

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

Questa classe avvolge intorno le informazioni fagioli e le uscite chiamata di metodo, inclusi i parametri, restituire valori e tempo di esecuzione a un log. Modificando il metodo writeToLog() si controlla dove si desidera produrre i dati e con quale gravità.

Ora è necessario un po 'di XML per selezionare in realtà che i fagioli che si sta per concludere:

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

In pratica si definiscono i fagioli che si desidera avvolgere con un carattere jolly in "beanNames" e "ordine" controlla l'ordinamento di wrapping: se non si dispone di altre classi AOP è possibile rimuoverlo. È inoltre possibile modificare il formato dell'output se si modificano le proprietà enterMessage e exitMessage.

Questo dovrebbe essere sufficiente per iniziare. Se hai bisogno di chiarimenti non esitare a chiedere.

Answer 2

L'approccio AOP funzionerebbe ma, a seconda di come si pianifica di registrare le informazioni, potrebbe influire sulle prestazioni stesse - è necessario essere consapevoli di ciò, assicurarsi che la registrazione sia efficiente possibile e assicurarsi che l'errore lo gestisca sul punto nel tuo aspetto

Si potrebbe anche voler guardare come Visual VM - Sono rimasto colpito da questo strumento, è facile da usare ed è stato in grado di fornirmi solo le informazioni di cui avevo bisogno quando l'ho usato l'ultima volta.

Answer 3

Accanto a VisualVM che Nick ha menzionato un altro software (e gratuito per lo sviluppo) è Oracle JRockit Mission Control. La sua console di gestione has the ability per le chiamate al profilo semplice di alcuni metodi (in più ci sono più opzioni di profilazione e sicuramente più veloce di TPTP).

Come per il sistema di misurazione tempo prima/dopo chiamate di metodo: in pratica funziona ma presenta alcuni "difetti" minori (ad esempio le applicazioni in background possono "alterare" il risultato).

Personalmente vorrei andare prima con VisualVM o JRockit Mission Control.

Answer 4

Il problema con "profiler 101" è che racchiude molte idee la cui giustificazione è più una questione di popolarità che un buon pensiero.

La più grande idea del genere è che il modo migliore per trovare i problemi di prestazioni è misurando le prestazioni.

Questo è il modo top-down, ed è come cercare di trovare rifiuti nel governo guardando il budget di ogni dipartimento. Un'alternativa è un approccio dal basso verso l'alto, come il prelievo di diverse unità casuali di denaro o tempo e (la più importante) che determina completamente perché viene speso ogni.

Se ci sono rifiuti, questo lo troverà rapidamente. La ragione è semplice, se una percentuale (circa il 40%) viene sprecata, allora quella percentuale di campioni (in media) ti mostrerà esattamente come viene sprecata.

This is the language-agnostic method I use.

AGGIUNTO: Si può pensare una grande frazione come il 40% non è realistico, perché non si può immaginare, but it's entirely possible.