Ottimizzare un'app Go

In questo tutorial, eseguirai il deployment di un'applicazione Go intenzionalmente inefficiente configurato per raccogliere i dati del profilo. Utilizzi Profiler per visualizzare i dati del profilo e identificare potenziali ottimizzazioni. Poi potrai modificare l'applicazione, eseguirne il deployment e valutare l'effetto modifica.

Prima di iniziare

1. Accedi al tuo account Google Cloud. Se non conosci Google Cloud, crea un account per valutare le prestazioni dei nostri prodotti in scenari reali. I nuovi clienti ricevono anche 300 $di crediti gratuiti per l'esecuzione, il test e il deployment dei carichi di lavoro.

2. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

   Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

   Go to project selector

3. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

   Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

   Go to project selector

4. Attiva l'API richiesta.

   Abilita l'API

5. Per aprire Cloud Shell, nella barra degli strumenti della console Google Cloud, fai clic su Attiva Cloud Shell:

   

   Dopo qualche istante, si apre una sessione di Cloud Shell all'interno Console Google Cloud:

   

Applicazione di esempio

L'obiettivo principale è massimizzare il numero di query al secondo che che il server può elaborare. Un obiettivo secondario è ridurre la memoria utilizzata mediante l'eliminazione di allocazioni di memoria non necessarie.

Il server, utilizzando un framework gRPC, riceve una parola o una frase e restituisce il numero di volte in cui la parola o la frase compare nelle opere di Shakespeare.

Il numero medio di query al secondo che il server è in grado di gestire è determinato dal test di carico del server. Per ogni serie di test, un client il simulatore viene chiamato e gli viene chiesto di inviare 20 query sequenziali. Al termine di una sessione, il numero di query inviate dal client simulatore, il tempo trascorso e il numero medio di query al secondo vengono visualizzati.

Il codice del server è intenzionalmente inefficiente.

Esecuzione dell'applicazione di esempio

Nota: il tempo di esecuzione dell'applicazione è solo abbastanza lungo da raccogliere alcuni dati del profilo. In pratica, è auspicabile avere almeno 10 profili prima di analizzare i dati del profilo.

Scarica ed esegui l'applicazione di esempio:

1. In Cloud Shell, esegui questi comandi:

   git clone https://github.com/GoogleCloudPlatform/golang-samples.git
   cd golang-samples/profiler/shakesapp
   

2. Esegui l'applicazione con la versione impostata su 1 e il numero di cicli impostati su 15:

   go run . -version 1 -num_rounds 15
   

   Dopo uno o due minuti, vengono visualizzati i dati del profilo. I dati del profilo si presentano simile all'esempio seguente:

   

   Nello screenshot, nota che il Tipo di profilo è impostato su CPU time. Ciò indica che i dati sull'utilizzo della CPU vengono visualizzati nel grafico a fiamme.

   Di seguito è riportato l'output di esempio stampato in Cloud Shell:

   $ go run . -version 1 -num_rounds 15
   2020/08/27 17:27:34 Simulating client requests, round 1
   2020/08/27 17:27:34 Stackdriver Profiler Go Agent version: 20200618
   2020/08/27 17:27:34 profiler has started
   2020/08/27 17:27:34 creating a new profile via profiler service
   2020/08/27 17:27:51 Simulated 20 requests in 17.3s, rate of 1.156069 reqs / sec
   2020/08/27 17:27:51 Simulating client requests, round 2
   2020/08/27 17:28:10 Simulated 20 requests in 19.02s, rate of 1.051525 reqs / sec
   2020/08/27 17:28:10 Simulating client requests, round 3
   2020/08/27 17:28:29 Simulated 20 requests in 18.71s, rate of 1.068947 reqs / sec
   ...
   2020/08/27 17:44:32 Simulating client requests, round 14
   2020/08/27 17:46:04 Simulated 20 requests in 1m32.23s, rate of 0.216849 reqs / sec
   2020/08/27 17:46:04 Simulating client requests, round 15
   2020/08/27 17:47:52 Simulated 20 requests in 1m48.03s, rate of 0.185134 reqs / sec
   

   L'output di Cloud Shell mostra il tempo trascorso per ogni iterazione. il tasso medio di richieste. Quando l'applicazione viene avviata, la voce "20 richieste simulate in 17,3 s, frequenza di 1,156069 richieste / sec" indica che il server esegue circa 1 richiesta al secondo. Nell'ultimo round, l'ingresso "20 richieste simulate in 1 m 48,03 s, frequenza di 0,185134 richieste / sec" indica il server esegue circa una richiesta ogni 5 secondi.

Utilizzo dei profili di tempo CPU per massimizzare le query al secondo

Un approccio per massimizzare il numero di query al secondo è identificare la CPU metodi ad alta intensità e ottimizzarne le implementazioni. In questa sezione, puoi utilizzare i profili di tempo CPU per identificare un metodo che richiede molta CPU nel server.

Identificazione dell'utilizzo del tempo di CPU

Il frame principale del grafico a fiamme elenca il tempo totale di CPU utilizzato dell'applicazione nell'intervallo di raccolta di 10 secondi:

In questo esempio, il servizio ha utilizzato 2.37 s. Quando il sistema viene eseguito su una singola core, un utilizzo del tempo di CPU di 2,37 secondi corrisponde al 23,7% di utilizzo di quello principale. Per ulteriori informazioni, vedi Tipi di profilazione disponibili.

Modifica dell'applicazione

Passaggio 1: quale funzione richiede tempo di CPU?

Un modo per identificare il codice che potrebbe dover essere ottimizzato è visualizzare la tabella delle funzioni e identificare le funzioni greedy:

1. Per visualizzare la tabella, fai clic su Imposta lo stato attivo sull'elenco delle funzioni.
2. Ordina la tabella per Totale. La colonna con l'etichetta Totale mostra l'utilizzo del tempo di CPU da parte di una funzione e dei relativi figli.

   In questo esempio, GetMatchCount è il primo Funzione shakesapp/server.go elencata. Questa funzione ha utilizzato 1,7 secondi del tempo di CPU totale, o il 72% del tempo di CPU totale delle applicazioni. È noto che questa funzione gestisce le richieste gRPC.

   

   Il grafico a fiamme mostra che shakesapp/server.go funzione GetMatchCount chiama MatchString, che a sua volta spende la maggior parte del suo Orario chiamata Compile:
   

   

Passaggio 2. Come puoi utilizzare le nozioni apprese?

1. Affidati alla tua esperienza linguistica. MatchString è un metodo di espressione regolare. Sai che l'elaborazione delle espressioni regolari è molto flessibile, ma non necessariamente è la soluzione più efficiente per ogni problema.
2. Affidati all'esperienza delle tue applicazioni. Il client sta generando una parola o frase e il server sta cercando questa frase.
3. Cerca l'implementazione Metodo shakesapp/server.go GetMatchCount per gli utilizzi di MatchString, quindi determina se una funzione più semplice ed efficiente potesse sostituire quella chiamata.

Passaggio 3: come puoi modificare l'applicazione?

Nel file shakesapp/server.go, il valore il codice esistente contiene una chiamata al numero MatchString:

    isMatch, err := regexp.MatchString(query, line)
    if err != nil {
           return resp, err
    }
    if isMatch {
           resp.MatchCount++
    }
    

Un'opzione è sostituire la logica MatchString con logica equivalente che utilizza strings.Contains:

    if strings.Contains(line, query) {
            resp.MatchCount++
    }
    

Assicurati di rimuovere l'istruzione di importazione per regexp pacchetto.

Valutare la modifica

Per valutare la modifica:

1. Esegui l'applicazione con la versione impostata su 2:

   go run . -version 2 -num_rounds 40
   

   Una sezione successiva mostra che, con l'ottimizzazione, il tempo necessario un singolo round è molto inferiore a quello dell'applicazione non modificata. Per garantire che l'applicazione venga eseguita abbastanza a lungo da raccogliere di caricamento dei profili, il numero di cicli aumenta.

2. Attendi il completamento dell'applicazione, quindi visualizza i dati del profilo per questa versione dell'applicazione:

   • Fai clic su ORA per caricare i dati del profilo più recenti. Per ulteriori informazioni, consulta Intervallo di tempo.
   • Nel menu Versione, seleziona 2.

Ad esempio, il grafico a fiamme è il seguente:

In questa figura, il frame principale mostra il valore 7.8 s. In seguito a cambiando la funzione di corrispondenza della stringa, il tempo di CPU usato dall'applicazione è passato da 2,37 secondi a 7,8 secondi, o l'applicazione è passata dall'utilizzo il 23,7% di un core della CPU all'utilizzo del 78% di un core della CPU.

La larghezza del frame è una misura proporzionale dell'utilizzo del tempo di CPU. In questo ad esempio, la larghezza del frame per GetMatchCount indica che questa funzione utilizza circa il 49% di tutto il tempo di CPU impiegato dall'applicazione. Nel grafico a fiamme originale, lo stesso frame corrispondeva a circa il 72% della larghezza del grafico. Per visualizzare l'utilizzo esatto del tempo di CPU, puoi usare la descrizione comando del frame Elenco delle funzioni in evidenza:

L'output in Cloud Shell mostra che versione modificata completa circa 5,8 richieste al secondo:

$ go run . -version 2 -num_rounds 40
2020/08/27 18:21:40 Simulating client requests, round 1
2020/08/27 18:21:40 Stackdriver Profiler Go Agent version: 20200618
2020/08/27 18:21:40 profiler has started
2020/08/27 18:21:40 creating a new profile via profiler service
2020/08/27 18:21:44 Simulated 20 requests in 3.67s, rate of 5.449591 reqs / sec
2020/08/27 18:21:44 Simulating client requests, round 2
2020/08/27 18:21:47 Simulated 20 requests in 3.72s, rate of 5.376344 reqs / sec
2020/08/27 18:21:47 Simulating client requests, round 3
2020/08/27 18:21:51 Simulated 20 requests in 3.58s, rate of 5.586592 reqs / sec
...
2020/08/27 18:23:51 Simulating client requests, round 39
2020/08/27 18:23:54 Simulated 20 requests in 3.46s, rate of 5.780347 reqs / sec
2020/08/27 18:23:54 Simulating client requests, round 40
2020/08/27 18:23:58 Simulated 20 requests in 3.4s, rate of 5.882353 reqs / sec

La piccola modifica all'applicazione ha avuto due diversi effetti:

• Il numero di richieste al secondo è aumentato da meno di 1 al secondo a 5,8 al secondo.

• Il tempo di CPU per richiesta, calcolato dividendo l'utilizzo della CPU per il il numero di richieste al secondo è sceso al 13,4% dal 23,7%.

  Tieni presente che il tempo di CPU per richiesta è diminuito anche se l'utilizzo del tempo di CPU aumentato da 2,37 secondi, che corrisponde al 23,7% di utilizzo di un un singolo core della CPU, fino a 7,8 secondi, o il 78% di un core della CPU.

Utilizzo di profili heap allocati per migliorare l'utilizzo delle risorse

Questa sezione illustra come utilizzare l'heap e i profili heap allocati per identificare un metodo ad alta allocazione nell'applicazione:

• I profili heap mostrano la quantità di memoria allocata nell'heap del programma nel momento in cui il profilo viene raccolto.

• I profili heap allocati mostrano la quantità totale di memoria allocata nell'heap del programma durante l'intervallo in cui il profilo raccolte. Dividendo questi valori per 10 secondi, il valore di raccolta dei profili, puoi interpretarli come tassi di allocazione.

Abilitazione della raccolta di profili heap in corso...

1. Esegui l'applicazione con la versione impostata su 3 e abilita la raccolta dei profili heap allocati e allocati.

   go run . -version 3 -num_rounds 40 -heap -heap_alloc
   

2. Attendi il completamento dell'applicazione, quindi visualizza i dati del profilo per questa versione dell'applicazione:

   • Fai clic su ORA per caricare i dati del profilo più recenti.
   • Nel menu Versione, seleziona 3.
   • Nel menu Tipo di profiler, seleziona heap allocato.

   Ad esempio, il grafico a fiamme è il seguente:

   

Identificazione del tasso di allocazione heap

Il frame principale visualizza la quantità totale di heap allocata durante 10 secondi durante la raccolta di un profilo, la media di tutti i profili. In questo esempio, il frame radice mostra che, in media, 1,535 GiB di è stata allocata.

Modifica dell'applicazione

Passaggio 1: vale la pena ridurre al minimo il tasso di allocazione heap?

L'utilizzo del tempo di CPU della funzione di garbage collection del background Go, runtime.gcBgMarkWorker.*, può essere utilizzato per determinare se vale la pena ottimizzare l'applicazione per ridurre i costi di garbage collection:

• Salta l'ottimizzazione se l'utilizzo del tempo di CPU è inferiore al 5%.
• Eseguire l'ottimizzazione se l'utilizzo del tempo di CPU è di almeno il 25%.

Per questo esempio, l'utilizzo del tempo di CPU il garbage collector in background è il 16,8%. Questo valore è sufficientemente alto vale la pena provare a ottimizzare shakesapp/server.go:

Passaggio 2: quale funzione alloca molta memoria?

Il file shakesapp/server.go contiene due funzioni che potrebbero essere target per l'ottimizzazione: GetMatchCount e readFiles. Per determinare la frequenza di allocazione della memoria per queste funzioni, imposta Tipo di profilo su heap allocato, quindi utilizza Imposta lo stato attivo sull'elenco delle funzioni.

In questo esempio, l'allocazione totale dell'heap per readFiles.func1 durante la raccolta del profilo di 10 secondi è, in media, 1,045 GiB o il 68% la memoria allocata totale. L'allocazione dell'heap autonomo durante i 10 secondi la raccolta del profilo è di 255,4 MiB:

In questo esempio, il metodo Go makeSlice ha allocato 798,7 MiB durante la raccolta del profilo di 10 secondi. Il modo più semplice per ridurre queste allocazioni è ridurre le chiamate al numero makeSlice. La chiamate alla funzione readFiles makeSlice tramite un metodo libreria.

I risultati di questa analisi suggeriscono che potrebbe essere possibile ridurre il tasso di allocazioni dell'heap mediante l'ottimizzazione di readFiles.

Passaggio 3: come puoi modificare l'applicazione?

Un'opzione è modificare l'applicazione per leggere i file una volta e e riutilizzarli. Ad esempio, potresti creare quanto segue modifiche:

1. Definisci una variabile globale files per archiviare i risultati dell'evento lettura del file iniziale:

   var files []string

2. Modifica readFiles per restituire in anticipo quando files è definito:

          func readFiles(ctx context.Context, bucketName, prefix string) ([]string, error) {
                   
                   // return if defined
                   if files != nil {
                           return files, nil
                   }
                   
   
                   // Existing
                   type resp struct {
                           s   string
                           err error
                   }
                   ...
                   
                   // Save the result in the variable files
                   files = make([]string, len(paths))
                   for i := 0; i < len(paths); i++ {
                           r := <-resps
                           if r.err != nil {
                                   return nil, r.err
                           }
                           files[i] = r.s
                   }
                   return files, nil
                   
           }
           

Valutare la modifica

Per valutare la modifica:

1. Esegui l'applicazione con la versione impostata su 4:

   go run . -version 4 -num_rounds 60 -heap -heap_alloc
   

2. Attendi il completamento dell'applicazione, quindi visualizza i dati del profilo per questa versione dell'applicazione:

   • Fai clic su ORA per caricare i dati del profilo più recenti.
   • Nel menu Versione, seleziona 4.
   • Nel menu Tipo di profiler, seleziona heap allocato.

3. Per quantificare l'effetto della modifica di readFiles sul tasso di allocazione heap: confronta i profili heap allocati per la versione 4 con quelli raccolti per la versione 3:

   

   La descrizione comando del frame principale mostra che con la versione 4, la quantità media di di memoria allocata durante la raccolta dei profili diminuita di 1,301 GiB, rispetto alla versione 3. La descrizione comando per readFiles.func1 mostra una diminuzione di 1,045 GiB:

   

4. Per quantificare l'effetto sulla garbage collection, configura un confronto delle CPU profili temporali. Nello screenshot seguente viene applicato un filtro per mostrare gli stack per il garbage collector di Go runtime.gcBgMarkWorker.*. Lo screenshot mostra che L'utilizzo della CPU per la garbage collection si riduce dal 16,8% al 4,97%.

   

5. Per determinare se esiste un impatto della modifica sul numero di richieste al secondo gestito dall'applicazione, visualizza l'output in Cloud Shell. In questo esempio, la versione 4 completa fino a 15 richieste per , che è notevolmente superiore alle 5,8 richieste al secondo di Versione 3:

   $ go run . -version 4 -num_rounds 60 -heap -heap_alloc
   2020/08/27 21:51:42 Simulating client requests, round 1
   2020/08/27 21:51:42 Stackdriver Profiler Go Agent version: 20200618
   2020/08/27 21:51:42 profiler has started
   2020/08/27 21:51:42 creating a new profile via profiler service
   2020/08/27 21:51:44 Simulated 20 requests in 1.47s, rate of 13.605442 reqs / sec
   2020/08/27 21:51:44 Simulating client requests, round 2
   2020/08/27 21:51:45 Simulated 20 requests in 1.3s, rate of 15.384615 reqs / sec
   2020/08/27 21:51:45 Simulating client requests, round 3
   2020/08/27 21:51:46 Simulated 20 requests in 1.31s, rate of 15.267176 reqs / sec
   ...
   

   L'aumento delle query al secondo gestite dall'applicazione potrebbe essere dovuto a di tempo per la garbage collection.

• È possibile ottenere una comprensione più completa dell'effetto della modifica a readFiles visualizzando i profili heap. Un confronto tra profili heap dalla versione 4 a quella della versione 3 indica che l'utilizzo dell'heap è diminuito a 18,47 MiB da 70,95 MiB:

  

Riepilogo

In questa guida rapida sono stati utilizzati il tempo di CPU e i profili heap allocati per identificare potenziali ottimizzazioni di un'applicazione. L'obiettivo era massimizzare il numero di richieste al secondo ed eliminare allocazioni.

• Utilizzando i profili di tempo della CPU, è stata identificata una funzione che richiede un uso intensivo della CPU. Dopo aver applicato una semplice modifica, il tasso di richieste del server è aumentato a 5,8 al secondo, da circa 1 al secondo.

• Utilizzando i profili heap allocati, shakesapp/server.go è stata identificata la funzione readFiles con un tasso di allocazione elevato. Dopo aver ottimizzato readFiles, la tasso di richieste del server è aumentata a 15 richieste al secondo e la media quantità di memoria allocata durante la raccolta del profilo di 10 secondi è diminuito di 1,301 GiB.

Passaggi successivi

• Per informazioni su come i profili vengono raccolti e inviati al tuo progetto Google Cloud, consulta Raccolta profilo.

• Leggi le nostre risorse su DevOps ed esplora il nostro programma di ricerca.

Per informazioni sull'esecuzione dell'agente Cloud Profiler, consulta:

• Profilazione delle applicazioni Go
• Profilazione delle applicazioni Java
• Profilazione delle applicazioni Node.js
• Profilazione delle applicazioni Python
• Profilazione delle applicazioni in esecuzione al di fuori di Google Cloud