Come hai trovato le prestazioni lente nella tua applicazione?

La chiave per rintracciare i problemi di prestazioni è:

1. Scopri quando esistono.
2. Avere un contesto sufficiente per capire cosa stava andando storto quando erano lenti.

La chiave per entrambi è la registrazione. L'ideale è avere la registrazione con livelli di registrazione opzionali che consentiranno di visualizzare più dettagli che possono essere attivati selettivamente.

Per un ottimo esempio di ciò che funziona, dai un'occhiata a Oracle. In ogni momento, come parte delle funzionalità di base del sistema, tiene traccia di quali query sono state eseguite e per quanto tempo hanno impiegato. I DBA possono andare e guardare la situazione per capire dove vanno le prestazioni. (Non limitarti a guardare cose lente, in un sistema sotto carico una query veloce molto comune può essere un problema più grande di una occasionale lente.) Inoltre hai la possibilità di prendere una query, eseguirla e fare uscire Oracle una traccia dettagliata di esattamente quello che è successo e dove è andato il tempo. Sulla base di tali discariche è possibile per un DBA esperto capire esattamente cosa è successo e dove si trova il collo di bottiglia.

Sì, c'è un sovraccarico costante dovuto alla presenza di questo monitoraggio. Cercano di minimizzarlo, ma è ancora lì. Tuttavia, la prima volta che ti aiuta a individuare un collo di bottiglia per le prestazioni che non avevi realizzato era lì, si ripaga da solo. Senza monitoraggio, stai pregando che non crei problemi sciocchi. La preghiera non è semplicemente un modo affidabile per raggiungere la scalabilità.

Se hai un sistema complesso con molti RPC, la vita diventa più complicata. La sfortunata realtà è che rintracciare una richiesta front-end apparentemente casuale a un RPC con diversi livelli di profondità che possono o non possono sparare possono trasformarsi in un incubo. La soluzione, che praticamente nessuno fa, è quella di avere il meccanismo RPC in grado di etichettare una piccola parte delle richieste come "proiettili traccianti". Quelle richieste e tutti gli RPC in modo ricorsivo attraverso il tuo sistema verranno registrati nei dettagli e quei log raccolti insieme per fornire un'immagine accurata di tali richieste. Certo, c'è un sovraccarico nel farlo. Ecco perché qualcosa come lo 0,1% delle richieste viene registrato in quel dettaglio. Ma quando il sistema ha dei problemi, ora puoi entrare e cercare una richiesta di tracciamento lenta, aprirla e vedere immediatamente dove si trova il problema delle prestazioni.

Sì, questo è un sacco di lavoro. Sì, è invasivo. Ma non posso sottolineare abbastanza quanto sia importante avere questo in un sistema complesso e di grandi dimensioni. Come dice il vecchio proverbio, la mancata pianificazione ha intenzione di fallire. Se non hai un piano per capire i problemi di prestazioni, quando succedono non hai un modo per capirli.

Ho anche implementato sistemi di monitoraggio delle prestazioni di produzione per aiutare a identificare i problemi di prestazioni; la chiave, ovviamente, è assicurarsi che il monitoraggio delle prestazioni non ostacoli la performance stessa!

In realtà, un semplice monitor delle prestazioni che (in un esempio di applicazione Web) registra solo il tempo necessario per completare una richiesta e quanto tempo è necessario per il rendering di una pagina per concentrare gli sforzi sulle richieste o sui tipi di richieste che sono i più lenti o presentano il carico maggiore (tempo medio di esecuzione * numero di esecuzioni), e quindi sono buoni obiettivi per l'ottimizzazione. Quindi, utilizzando una piattaforma di test e i passaggi di base indicati nella domanda, è possibile restringere la causa dei problemi di prestazioni e inizia le tue ottimizzazioni.

A seconda della situazione, è anche opportuno monitorare singolarmente i processi dipendenti: prestazioni del database dei profili, prestazioni del disco e così via, per garantire che tutte le parti mobili dell'intero sistema funzionino nel modo più fluido possibile. Un'applicazione perfettamente ottimizzata può essere rallentata fino alla scansione da un database con prestazioni scadenti.

Preferisco non avere il monitoraggio delle prestazioni nel mio codice di produzione. Cerco di avere una buona copertura del test unitario (ogni metodo significativo ha almeno un test unitario). Visual Studio imposta automaticamente il tempo necessario per eseguire ogni test dell'unità. Per una panoramica generale, eseguo tutti i test per avere un'idea generale di dove potrebbero essere i colli di bottiglia.

Per un'applicazione web, la tempistica delle singole richieste è un buon inizio. Firebug funziona bene per questo. Se lo abbini al suggerimento di Ironcode per fare affidamento sui test unitari, dovresti riuscire a localizzare la maggior parte dei colli di bottiglia.

Oltre a ciò ... dipende dalla tua app. Esistono vari strumenti che è possibile utilizzare per profilare vari aspetti del codice. Ad esempio, se stai utilizzando Hibernate, ti consente di raccogliere statistiche sulla durata di tutte le query del database per completare.

Bene, di solito sono gli utenti a lamentarsi che l'app è lenta (-:

A parte l'umorismo, ecco alcune cose che ho trovato utili in base a come verrà utilizzata l'app, da chi e quando:

• Identifica quali parti dell'app sono lente (app esistente) o non possono essere lente (nuova app). Questo può venire dagli utenti, dalla tua esperienza o dai requisiti di prestazione. Identifica anche quali casi d'uso sono lenti, il che può aiutare a restringere l'ambito. Ad esempio, se i casi d'uso che non hanno interazione con DB sono lenti, puoi escludere problemi con DB.

• Identifica le volte in cui l'app è lenta. "Sempre lento" è diverso da "Lento il lunedì tra le 9 e le 10". Forse c'è un backup del DB che viene eseguito in quel momento. Forse ci sono 10 utenti in più sul sistema in quel momento.

• Chiedi al tuo DBA di eseguire statistiche e rapporti per i tempi in cui la tua app è lenta.

• Chiedi al tuo amministratore di sistema di eseguire statistiche sul file system per Disk I / O, CPU, RAM e altro consumo di risorse di questo tipo.

• Chiedi al tuo amministratore di rete di eseguire statistiche sul traffico di rete tra i vari server.

• Analizza i registri. Questo può variare dall'abilitazione di% T nel formato di registro Apache all'impostazione del formato di registro in "DEBUG" (Nota: l'accesso agli ambienti di produzione è solitamente impostato su "ERRORE", quindi è meglio farlo in un ambiente più basso come Test).

• Se stai eseguendo un'applicazione basata su Java, prendi i dump di heap e di heap. Analizzali per serrature o perdite di memoria. Memory Analysis Tool è uno strumento utile per l'analisi heap dump e credo che possa essere usato come plugin con Eclipse. Abilita i log della raccolta dati inutili e analizzali anche.

• Se la tua organizzazione può permettersi strumenti di profilazione COTS come Panorama e ACE di OPNet, o gli strumenti di NewRelic, provali anche tu.

Sembra che tu sia a conoscenza di alcuni di questi concetti. Sto inoltrando la mia risposta per un pubblico generale che potrebbe avere o meno familiarità con queste idee.

In ogni caso, HTH,

KM

Per quanto ne so, nelle applicazioni aziendali, ci sono solitamente NFR presenti che dichiarano l'efficacia generale del sistema sotto test. Dal mio progetto, funziona così:

-il cliente specifica ciò che intende "efficace", "reattivo", ecc.

-siamo preparare un esempio di testdata (non "speriamo per il migliore" set di dati, ma "andiamo su questa app come non c'è il domani" set di dati) e prepariamo scenari di utilizzo da eseguire.

-quindi, lo lasciamo girare e bruciamo alcuni cicli della CPU, come per 48/72 ore, e raccogliamo le statistiche generali del sistema (in questo modo non dobbiamo inserire nell'app un'apposita e non realistica codice di monitoraggio).

- alla fine è possibile dire che c'è un problema specifico (ad esempio il sistema dovrebbe fare 10k transazioni all'ora, ma fa solo 2k - questo è il collo di bottiglia delle prestazioni da qualche parte), e dovremmo essere in grado di dire quale utilizzo combinazione di scenario / dati ha causato un comportamento indesiderato. D'ora in poi, è possibile imitare esempi specifici in benchmark specifici e lavorare sulla soluzione.

Se hai bisogno di testare specificamente una webapp (ad esempio la reattività dell'interfaccia in condizioni di stress), puoi prendere in considerazione l'utilizzo del selenio distribuito (credo che ci siano alcune società che offrono tali servizi, utilizzando i propri data center)