Concetti di profilazione
La profilazione è una forma di analisi del codice dinamica. Acquisisci le caratteristiche dell'applicazione durante l'esecuzione e poi utilizzi queste informazioni per identificare come rendere l'applicazione più veloce ed efficiente.
In passato, il profiling veniva eseguito solo durante lo sviluppo delle applicazioni. Questo approccio si basava sulla capacità di sviluppare test di carico e benchmark che potevano prevedere con precisione un ambiente di produzione.
La profilazione continua si riferisce alla profilazione dell'applicazione durante l'esecuzione in un ambiente di produzione. Questo approccio riduce la necessità di sviluppare test di carico predittivi e benchmark accurati per l'ambiente di produzione. La ricerca sulla profilazione continua ha dimostrato che è accurata e rientra nel budget*.
Cloud Profiler è uno strumento di profilazione continua progettato per le applicazioni in esecuzione su Google Cloud:
Si tratta di un profiler statistico o basato su campionamento con un overhead ridotto ed è adatto per gli ambienti di produzione.
Supporta le lingue comuni e raccoglie più tipi di profili. Per una panoramica, consulta Tipi di profilazione disponibili.
La configurazione di un'applicazione Google Cloud per generare dati di profilo è un processo semplice e una tantum: collega o esegui il servizio con un agente di profilazione incluso. Dopo il deployment dell'applicazione, l'agente di profilazione viene eseguito periodicamente per raccogliere i dati sul rendimento e poi li invia al tuo progetto Google Cloud. Per informazioni dettagliate su questa procedura, consulta la sezione Raccolta dei profili.
Dopo aver raccolto i dati del profilo per la tua applicazione, puoi analizzarli utilizzando l'interfaccia Profiler. L'analisi dei dati del profilo è in genere un processo iterativo che si basa sulla tua conoscenza del design dell'applicazione e del suo linguaggio di programmazione.
*Consulta quanto segue: Profiling a livello di Google: un'infrastruttura di profilazione continua per i data center e Profiling continuo: che fine hanno fatto tutti i cicli?.
Tipi di profilazione disponibili
La seguente tabella riassume i tipi di profilo supportati:
| Tipo di profilo | Vai | Java | Node.js | Python |
|---|---|---|---|---|
| Tempo CPU | S | Y | S | |
| Heap | S | Y | S | |
| Heap allocato | S | |||
| Contesa | S | |||
| Thread | S | |||
| Tempo totale di esecuzione | S | Y | S |
Il resto di questa sezione fornisce maggiori dettagli su ciascuno di questi tipi di profilo.
Misurazioni del tempo
Il tempo di CPU è il tempo impiegato dalla CPU per eseguire un blocco di codice.
Il tempo di CPU di una funzione indica per quanto tempo la CPU è stata impegnata a eseguire le istruzioni. Non include il tempo in cui la CPU era in attesa o elaborava istruzioni per qualcos'altro.
Il tempo reale (chiamato anche tempo di sistema) è il tempo necessario per eseguire un blocco di codice.
Il tempo reale di una funzione misura il tempo che intercorre tra l'ingresso e l'uscita da una funzione. Il tempo reale include tutto il tempo di attesa, incluso quello per i blocchi e la sincronizzazione dei thread. Il tempo totale di esecuzione per un blocco di codice non può mai essere inferiore al tempo della CPU.
Se il tempo reale è più lungo del tempo della CPU, significa che il codice impiega tempo in attesa. Quando la differenza è significativa, la tua applicazione potrebbe avere un collo di bottiglia delle risorse.
Se il tempo della CPU è simile al tempo totale di esecuzione, significa che il codice richiede un'elevata intensità di CPU; quasi tutto il tempo necessario per l'esecuzione viene impiegato dalla CPU. I blocchi di codice a lungo termine che richiedono un'elevata intensità di risorse della CPU potrebbero essere candidati per l'ottimizzazione.
Utilizzo dell'heap (memoria)
L'utilizzo dell'heap (chiamato anche heap) è la quantità di memoria allocata nell'heap del programma nell'istante in cui viene raccolto il profilo. A differenza di altri tipi di profili in cui i dati vengono raccolti in un intervallo, questo tipo di profilo raccoglie l'utilizzo dell'heap in un singolo istante.
L'allocazione dell'heap (chiamato anche heap allocato) è la quantità totale di memoria allocata nell'heap del programma durante l'intervallo in cui è stato raccolto il profilo. Questo valore include la memoria che è stata allocata, è stata liberata e non è più in uso. Ad esempio, consideriamo un job che ripete la seguente sequenza: alloca 1 MiB, attende 500 ms, libera 1 MiB, attende 500 ms. Nei 10 secondi in cui viene raccolto il profilo dell'heap allocato, si verificano 10 allocazioni e 10 liberazioni. Questo profilo mostrerebbe 10 MiB di heap allocati, poiché gli spazi liberi non vengono considerati. La frequenza media di allocazione è 10 MiB/10 secondi o 1 MiB al secondo.
La profilazione dell'utilizzo dell'heap consente di trovare potenziali inefficienze e perdite di memoria nei programmi. Il profiling delle allocazioni dell'heap ti aiuta a sapere quali allocazioni causano il maggior lavoro per il garbage collector.
Informazioni sulla filettatura
Le applicazioni che creano thread possono essere interessate da thread bloccati e da perdite di thread:
- I thread bloccati sono thread creati, ma in attesa di un blocco. Al momento questi thread non sono in esecuzione e potrebbero non essere mai eseguiti. Tuttavia, un thread bloccato potrebbe essere eseguito.
- Le perdite di thread si verificano quando il numero di thread creati continua ad aumentare.
I thread bloccati sono una delle cause dei thread con perdite.
A livello di frame, il profilo Thread mostra il numero medio di thread che includono il frame. Questo tipo di profilo raccoglie l'utilizzo dei thread in un singolo punto nel tempo.
Contesa
In un programma multithread, il tempo di attesa per la serializzazione dell'accesso a una risorsa condivisa può essere significativo. Comprendere il comportamento delle contese può guidare la progettazione del codice e fornire informazioni per l'ottimizzazione delle prestazioni.
Raccolta di profili
Il ruolo dell'agente di profilazione è acquisire i dati del profilo dalla tua applicazione e trasmetterli al backend di Profiler utilizzando l'API Profiler. Ogni profilo è destinato a una singola istanza di un'applicazione e include quattro campi che ne identificano in modo univoco il deployment:
- Progetto Google Cloud
- Nome applicazione
- Zona di applicazione
- Versione dell'applicazione
Quando un agente è pronto a acquisire un profilo, emette un comando API Profiler al backend di Profiler. Il backend riceve questa richiesta e, nello scenario più semplice, risponde immediatamente all'agente. La risposta specifica il tipo di profilo da acquisire. In risposta, l'agente acquisisce il profilo e lo trasmette al backend. Infine, il backend di Profiler associa il profilo al tuo progetto Google Cloud. Puoi poi visualizzarlo e analizzarlo utilizzando l'interfaccia di Profiler.
La sequenza di handshake effettiva è più complessa di quanto descritto nel paragrafo precedente. Ad esempio, quando Profiler riceve una richiesta da un agente, il backend controlla il proprio database per determinare se ha ricevuto richieste precedenti dall'agente. In caso contrario, il backend aggiunge le informazioni sull'agente al proprio database. Viene creato un nuovo deployment se i campi di deployment dell'agente non corrispondono alle impostazioni di nessun altro agente registrato.
Ogni minuto, in media, per ogni implementazione e per ogni tipo di profilo, il backend seleziona un agente e gli chiede di acquisire un profilo. Ad esempio, se gli agenti di un deployment supportano la profilazione dell'heap e del tempo totale di esecuzione, in media vengono acquisiti due profili ogni minuto:
Per tutti i tipi di profilo, ad eccezione dell'utilizzo dell'heap e dei thread, un singolo profilo rappresenta i dati raccolti per 10 secondi.
I profili di utilizzo dell'heap e dei thread vengono raccolti in modo istantaneo.
Dopo che l'agente ha comunicato al backend di Profiler che è pronto a acquisire i dati, rimane inattivo finché il backend non risponde con il tipo di profilo da acquisire. Se hai 10 istanze di un'applicazione in esecuzione nello stesso deployment, devi creare 10 agenti di profilazione. Tuttavia, la maggior parte del tempo questi agenti sono inattivi. In un periodo di 10 minuti, puoi aspettarti 10 profili; in media ogni agente riceve una risposta per ogni tipo di profilo. È prevista una certa casualità, pertanto il numero effettivo potrebbe variare.
Il backend di Profiler utilizza le quote dell'API Profiler e i campi di implementazione dei profili per limitare i profili importati. Per informazioni su come visualizzare e gestire le quote di Profiler, consulta Quote e limiti.
Analisi dei dati
Dopo che Profiler ha raccolto i dati, puoi visualizzarli e analizzarli utilizzando l'interfaccia di Profiler.
Nella console Google Cloud, vai alla pagina Profiler:
Puoi trovare questa pagina anche utilizzando la barra di ricerca.