Concetti di profilazione

La profilazione è una forma di analisi del codice dinamico. Puoi acquisire le caratteristiche dell'applicazione durante il suo funzionamento, quindi utilizzare queste informazioni per capire come rendere l'applicazione più veloce ed efficiente.

Storicamente, la profilazione veniva eseguita solo durante lo sviluppo dell'applicazione. Questo approccio si basava sulla capacità di sviluppare test di carico e benchmark in grado di prevedere con precisione un ambiente di produzione.

La profilazione continua si riferisce alla profilazione dell'applicazione mentre è in esecuzione in un ambiente di produzione. Questo approccio riduce la necessità di sviluppare test di carico e benchmark predittivi accurati per l'ambiente di produzione. La ricerca sulla profilazione continua ha dimostrato che è accurata ed economica*.

Cloud Profiler è uno strumento di profilazione continua progettato per le applicazioni in esecuzione su Google Cloud:

  • È uno profiler statistico (o campionamento) con un overhead ridotto ed è adatto agli ambienti di produzione.

  • Supporta linguaggi comuni e raccoglie diversi tipi di profilo. Per una panoramica, consulta Tipi di profilazione disponibili.

La configurazione di un'applicazione Google Cloud per generare i dati del profilo è una semplice procedura che deve avvenire una sola volta: collegare o eseguire il servizio con un agente di profilazione incluso. Dopo il deployment dell'applicazione, l'agente di profilazione viene eseguito periodicamente per raccogliere i dati sulle prestazioni e li invia al tuo progetto Google Cloud. Per maggiori dettagli su questa procedura, consulta Raccolta dei profili.

Dopo aver raccolto i dati del profilo per la tua applicazione, puoi analizzarli utilizzando l'interfaccia di 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.

*Vedi le seguenti sezioni: Profilazione a livello di Google: un'infrastruttura di profilazione continua per i data center e Profilazione continua: dove sono finiti tutti i cicli?.

Tipi di profilazione disponibili

La tabella seguente riassume i tipi di profilo supportati:

Tipo di profilo Go Java Node.js Python
Tempo CPU YY Y
Heap YY Y
Heap allocato Y
Contesa Y
Thread Y
Tempo totale di esecuzione Y YY

La parte restante di questa sezione fornisce ulteriori dettagli su ciascuno di questi tipi di profilo.

Misurazioni del tempo

  • Il tempo CPU è il tempo che la CPU impiega per eseguire un blocco di codice.

    Il tempo di CPU per una funzione indica per quanto tempo la CPU è stata impegnata nell'esecuzione delle istruzioni. Non include il tempo in cui la CPU era in attesa o ha elaborato le istruzioni per qualcos'altro.

  • Tempo reale (chiamato anche tempo reale) è il tempo necessario per eseguire un blocco di codice.

    L'orario reale di una funzione misura il tempo trascorso tra l'entrata e l'uscita da una funzione. I tempi di attesa includono tutti i tempi di attesa, anche quelli per blocchi e sincronizzazione dei thread. Il tempo totale di esecuzione per un blocco di codice non può mai essere inferiore al tempo di CPU.

Se il tempo di attesa è maggiore di quello di CPU, indica che il codice rimane in attesa. Quando la differenza è sostanziale, l'applicazione potrebbe avere un collo di bottiglia delle risorse.

Se il tempo di CPU è simile al tempo totale di esecuzione, significa che il codice utilizza molta CPU; quasi tutto il tempo necessario per l'esecuzione viene speso dalla CPU. Blocchi di codice a lunga esecuzione che richiedono molta CPU potrebbero essere candidati per l'ottimizzazione.

Utilizzo heap (memoria)

  • L'utilizzo heap (chiamato anche heap) è la quantità di memoria allocata nell'heap del programma nel momento in cui il profilo viene raccolto. A differenza degli altri tipi di profilo in cui i dati vengono raccolti in un intervallo, questo tipo di profilo raccoglie l'utilizzo dell'heap in un singolo momento.

  • L'allocazione dell'heap (detta anche heap allocata) è la quantità totale di memoria allocata nell'heap del programma durante l'intervallo in cui il profilo è stato raccolto. Questo valore include la memoria che è stata allocata e liberata e non è più in uso. Ad esempio, considera un job che ripete la seguente sequenza: alloca 1 MiB, attende 500 msec, libera 1 MiB, attende 500 msec. Nei 10 secondi in cui viene raccolto il profilo heap allocato, sono presenti 10 allocazioni e 10 operazioni gratuite. Questo profilo mostrerà 10 MiB di heap allocato, poiché i gratuiti 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. La profilazione delle allocazioni dell'heap consente di sapere quali allocazioni stanno generando il maggior lavoro per il garbage collector.

Informazioni sui thread

Le applicazioni che creano thread possono essere interessate da thread bloccati e fughe di thread:

  • I thread bloccati sono thread creati, ma in attesa di un blocco. Questi thread non sono attualmente in esecuzione e potrebbero non essere mai eseguiti. Tuttavia, potrebbe essere eseguito un thread bloccato.
  • Le fughe di thread si verificano quando il numero di thread creati continua ad aumentare.

I thread bloccati sono una delle cause della perdita di thread.

A livello di frame, il profilo Thread mostra il numero medio di thread che includono quel frame. Questo tipo di profilo raccoglie l'utilizzo dei thread in un singolo momento.

Contesa

In un programma multi-thread, il tempo trascorso in attesa per serializzare l'accesso a una risorsa condivisa può essere significativo. Comprendere il comportamento dei conflitti può guidare la progettazione del codice e fornire informazioni per l'ottimizzazione delle prestazioni.

Raccolta profili

Il ruolo dell'agente del profiler è acquisire i dati del profilo dall'applicazione e trasmetterli al backend di Profiler utilizzando l'API Profiler. Ogni profilo per 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 applicazione

Quando un agente è pronto ad acquisire un profilo, invia un comando API Profiler al backend 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 quindi 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 altri agenti registrati.

Ogni minuto, in media, e per ogni deployment e tipo di profilo, il backend seleziona un agente e gli indica di acquisire un profilo. Ad esempio, se gli agenti per un deployment supportano la profilazione dell'heap e del tempo di esecuzione, in media vengono acquisiti due profili al minuto:

  • Per tutti i tipi di profilo, tranne l'utilizzo heap e i thread, un singolo profilo rappresenta i dati raccolti per 10 secondi.

  • L'utilizzo dell'heap e i profili dei thread vengono raccolti immediatamente.

Dopo che l'agente avvisa il backend di Profiler che è pronto ad acquisire dati, l'agente rimane inattivo fino a quando il backend non risponde con il tipo di profilo da acquisire. Se hai 10 istanze di un'applicazione in esecuzione sullo stesso deployment, creerai 10 agenti di profilazione. Tuttavia, la maggior parte delle volte questi agenti sono inattivi. Nell'arco di 10 minuti sono disponibili 10 profili; ogni agente riceve in media una risposta per ogni tipo di profilo. È prevista una randomizzazione, quindi il numero effettivo può variare.

Il backend Profiler utilizza le quote dell'API Profiler e i campi di deployment dei profili per limitare il numero di 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:

Vai a Profiler

Puoi trovare questa pagina anche utilizzando la barra di ricerca.