A volte mi viene in mente che la sfida più grande per un ingegnere quando trova che la sua applicazione peggiora in termini di prestazioni è la mancanza di informazioni sufficienti.
Immagina di passare attraverso il rapporto sul rendimento settimanale dal registro di accesso dell'applicazione e di ottenere tempi di risposta molto più bassi da luglio. Tutto quello che puoi fare è pregare per non peggiorare la prossima volta.
Senza ulteriori dettagli sul tipo e sulla natura della tua applicazione, è difficile dare più di suggerimenti generali:
Se non si dispone di informazioni sufficienti, è necessario raccogliere le informazioni necessarie. Se non hai un obiettivo difficile per quello che è un rendimento soddisfacente, devi averne uno (altrimenti non puoi dire se hai raggiunto l'obiettivo o meno):
Le informazioni vengono in genere raccolte in diversi modi:
Continua a perfezionare la tua conoscenza del problema e a trovare luoghi in cui migliorare finché non hai raggiunto il tuo obiettivo.
Puoi eseguire il software con un debugger o IDE?
Il debugger ha un pulsante "pausa" o puoi interrompere il programma digitando Ctrl-C o un tasto del genere?
Se il programma sta diventando più lento e lento, sta facendo almeno una cosa che non ha bisogno di fare e di fare sempre di più. Dal momento che potrebbe essere in esecuzione, diciamo, 1/3 del tempo in cui è attualmente in esecuzione, significa che 2/3 del tempo sta facendo cose che non ha bisogno di fare. Se riesci a scattare un'istantanea a raggi X in un momento casuale, è probabile che 2/3 vedrai che esegue le cose non necessarie.
Mettilo in pausa mentre è in esecuzione ed esamina cosa sta facendo e perché. Esamina in particolare ogni riga di codice sullo stack delle chiamate. Vedi se riesci a spiegare a te stesso o a qualcun altro esattamente perché, in dettaglio, è stato speso quel particolare istante di tempo. (Non è necessario misurare nulla. È necessario vedere se si può sbarazzarsi di ciò che sta facendo).
Ripeti l'operazione alcune volte, ad esempio 5 o 10 volte.
Se ciò che il programma sta facendo in quel momento non è realmente necessario, e lo sta facendo in più di una volta lo hai fermato, hai trovato qualcosa che puoi aggiustare che ti darà una grande accelerazione, garantita. Più grande è il problema, più velocemente lo troverai.
Non ha niente a che fare con i requisiti.
Non ha niente a che fare con le misurazioni.
Ha tutto a che fare con solo "casa delle pulizie", con questo metodo.
Ecco un esempio abbastanza tipico.
Modifica È la saggezza convenzionale ascoltare "misura misura" o "usare un profiler". Ciò che è non convenzionale è sentire quanta velocità è stata raggiunta in quel modo. Le poche volte in cui ho ascoltato i risultati del profiling, era pari al 10% - 40%, o un fattore compreso tra 1,1 e 1,4. È piuttosto anemico. Se viene trovata e risolta una serie di problemi, c'è un effetto composto, come mostrato nell'esempio sopra.
P.S. Ecco un esempio in C ++ di un aumento di 3 ordini di grandezza, contenente tutte le versioni del codice sorgente, copie di campioni e descrizione dettagliata di come è fatta. Alcuni programmatori hanno imparato / scoperto come farlo, ma la maggior parte non l'ha fatto. Non potrebbe essere più semplice. Fino ad oggi, sono ancora totalmente disorientato dal fatto che non sia una conoscenza comune. L'unica spiegazione che posso vedere è che gli insegnanti non funzionano con programmi abbastanza grandi da richiedere questo tipo di ottimizzazione. Quello che fanno è insegnare gprof , per nessun altro motivo se non quello che è lì, in modo che possano insegnarlo e andare avanti. Ciò che fa è infettare i loro studenti con tutti i miti della sintonizzazione delle prestazioni , che ha generato esattamente i problemi che descrivi.
P.P.S. Nel caso in cui il punto non sia chiaro, qualsiasi thread, sia esso da solo o tra migliaia, ha una certa quantità minima di lavoro che deve assolutamente fare per raggiungere il suo scopo. Qualunque cosa stia facendo al di là di ciò sta richiedendo più tempo. Nell'esempio collegato a sopra (che è solo un esempio particolare - ogni app è diversa) questi "colli di bottiglia" sono stati rimossi:
push_back
new e delete
Aggiunta fino a oltre 99% ! Rimuovendoli ottieni ordini di accelerazione della magnitudine.
Ora il tipo di cosa che sento è "Beh certo, è sciocco da fare 2, e 6 non era nemmeno necessario". Ehi, nolo contendere , ma che dire degli altri quattro "colli di bottiglia"? Se non li aggiusti, quanto ottieni?
Se vuoi un serio aumento di velocità, indipendentemente dal fatto che venga utilizzato o meno un profiler, devi pulire tutti i problemi ! Tutti quelli che mancheranno saranno i limitatori di velocità dominanti.
Sebbene la generazione di metriche sia utile, prendo il seguente approccio:
1 > Eseguire perfmon / task manager (su win) di top (unix) per vedere se CPU, disco, rete o memoria vengono utilizzati pesantemente / thrashing / flatlining e indagare a seconda dei casi. Idealmente disco / rete / memoria non dovrebbero essere utilizzati in nessun luogo vicino a tutte le risorse disponibili. La CPU al 100% è ok dove stai facendo qualcosa a livello di CPU. Verifica di non eseguire più thread rispetto a quelli della CPU (a meno che l'applicazione non sia leggera sull'uso della CPU e il disco non sia un problema).
2 > Esegui un test di isolamento per verificare se esistono processi concorrenti sull'hardware che utilizzano risorse che potrebbero influire sulle prestazioni.
3 > Controlla se la concorrenza (se applicabile, ad esempio l'app web) è aumentata. Se hai bisogno di guardare la tua domanda per trovare i colli di bottiglia che devono essere affrontati. Di solito questi saranno nel database (problema di blocco di indici e tabelle, query lente) ma potrebbero essere nella configurazione dell'infrastruttura (cioè abbastanza CPU, memoria)
4 > A questo punto probabilmente hai un problema con il volume di dati. Ora guarda per vedere cosa è cambiato. I file di dati diventano più grandi? le tabelle del database diventano più grandi? Se le dimensioni dei dati diventano più grandi, è necessario capire cosa sta facendo l'applicazione per determinare quale linea di condotta intraprendere. Se si utilizza un database, è necessario verificare che vengano utilizzati gli indici appropriati e che le query siano ottimizzate. Un profiler SQL è utile qui oltre all'ispezione visiva del codice (presumendo che tu conosca o conosca qualcuno competente nell'ottimizzazione del database) Stai cercando la query più lunga e le query più frequenti. Un'altra opzione è quella di esaminare l'archiviazione o eliminare dati vecchi o irrilevanti, se possibile. Inoltre chiedi se tutti i dati sono realmente necessari per essere elaborati / archiviati. Devi anche cercare la situazione di blocco, l'ispezione del codice e i profilatori SQL ti aiuteranno.
5 > Se l'applicazione richiede un uso intensivo della CPU, è possibile che si desideri ottimizzare le porzioni di codice della CPU. L'ispezione visiva, le istruzioni di tracciamento durante il monitoraggio dell'utilizzo della CPU e gli strumenti del profiler aiuteranno a identificare il codice che potrebbe essere modificato. La soluzione potrebbe essere quella di utilizzare un diverso algoritmo di attività di elaborazione rimuovi / ripianifica. Un set di occhi esperienza può essere di aiuto qui.
6 > rimuovere qualsiasi codice di debug / registrazione necessario. Rimuovi tutto ciò che non è realmente necessario per l'esecuzione.
Ancora una volta, la chiave è capire cosa e come funziona l'applicazione, e pensare a come questi passaggi interagiscono con l'hardware / database.
L'ottimizzazione delle prestazioni è un'abilità fondamentale in qualsiasi applicazione che colpisce un database. Ogni database ha un grande libro scritto su come sintonizzare perfromance. Prendi il libro per il backbase di dabase, legalo copertinalmente e poi inizia a seguire i passi necessari per identificare e risolvere i problemi di prestazioni. Se il tuo database è stato progettato da qualcuno senza questo know-how per cominciare, probabilmente hai una cattiva progettazione che ha anche query mal progettate e possibilmente indicizzazione scadente. In questo caso, potresti voler leggere sul refactoring dei database e probabilmente avrai bisogno di modifiche strutturali e di correzioni agli indici e alle query. È una cosa complessa, non puoi imparare tutto da domande su un sito come questo. Solo pregare che migliori sarà controproducente, ci sono molte cose che puoi fare per migliorarle. E sì, con il passare del tempo, vengono aggiunti uno e più dati, le query diventeranno più lente e lente soprattutto se sono mal progettate.
Esistono anche ragioni non di database per prestazioni scadenti, ma il sintonizzatore del database viene aggiornato correttamente ed è probabile che molti dei tuoi problemi andranno via.
Ah il vecchio problema di crescita dei dati ...
L'ho visto così tante volte:
Tutto questo può essere evitato se un pensiero viene posto all'inizio del progetto.
Leggi altre domande sui tag testing performance web-applications profiling