Se usó la API de Cloud Translation para traducir esta página.

Optimiza una app de Go

En este instructivo, implementarás una aplicación de Go intencionalmente ineficiente que esté configurada para recopilar datos de perfil. Usa la interfaz de Profiler para ver los datos de perfil e identificar posibles optimizaciones. A continuación, modificarás la aplicación, la implementarás y evaluarás el efecto de la modificación.

Antes de comenzar

Sign in to your Google Cloud account. If you're new to Google Cloud, create an account to evaluate how our products perform in real-world scenarios. New customers also get $300 in free credits to run, test, and deploy workloads.

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

Go to project selector

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

Go to project selector

Enable the required API.
Enable the API
Para abrir Cloud Shell, en la barra de herramientas de la consola de Google Cloud, haz clic en Activar Cloud Shell:

Después de unos momentos, se abrirá una sesión de Cloud Shell en la consola de Google Cloud:

Aplicación de muestra

El objetivo principal es maximizar la cantidad de consultas por segundo que el servidor puede procesar. Un objetivo secundario es reducir el uso de memoria cuando se eliminan las asignaciones de memoria innecesarias.

El servidor, mediante un framework de gRPC, recibe una palabra o frase y, luego, muestra la cantidad de veces que la palabra o frase aparece en las obras de Shakespeare.

La cantidad promedio de consultas por segundo que el servidor puede manejar se determina mediante una prueba de carga del servidor. Para cada ronda de pruebas, se llama a un simulador de cliente, y se le solicita que emita 20 consultas secuenciales. Cuando se completa una ronda, se muestra la cantidad de consultas que envió el simulador de cliente, el tiempo transcurrido y la cantidad promedio de consultas por segundo.

El código del servidor es intencionalmente ineficiente.

Ejecuta la aplicación de muestra

Descarga y ejecuta la aplicación de muestra:

En Cloud Shell, ejecuta los siguientes comandos:

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

Ejecuta la aplicación con la versión establecida en 1 y la cantidad de rondas configuradas en 15:
```
go run . -version 1 -num_rounds 15
```
Después de un minuto o dos, se muestran los datos de perfil: Los datos del perfil son similares al siguiente ejemplo:

En la captura de pantalla, observa que el Tipo de perfil está configurado como CPU time. Esto indica que los datos de uso de la CPU se muestran en el gráfico tipo llama.

A continuación, se proporciona un resultado de muestra impreso en 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
```
El resultado de Cloud Shell muestra el tiempo transcurrido para cada iteración y el porcentaje de solicitudes promedio: Cuando se inicia la aplicación, la entrada "Simulación de 20 solicitudes en 17.3 s, la tasa de 1.156069 solicitudes por segundo" indica que el servidor se ejecuta alrededor de 1 solicitud por segundo. En la última ronda, la entrada "Simulación de 20 solicitudes en 1m48.03 s, la tasa de 0.185134 solicitudes por segundo" indica que el servidor se está ejecutando a 1 solicitud cada 5 segundos.

Usa perfiles de tiempo de CPU para maximizar las consultas por segundo

Un enfoque para maximizar la cantidad de consultas por segundo es identificar los métodos con uso intensivo de CPU y optimizar sus implementaciones. En esta sección, usarás perfiles de tiempo de CPU para identificar un método de uso intensivo de CPU en el servidor.

Identifica el uso del tiempo de CPU

El marco raíz del gráfico tipo llama muestra una lista del tiempo total de CPU que usó la aplicación en el intervalo de recopilación de 10 segundos:

Vista expandida del marco raíz del gráfico tipo llama

En este ejemplo, el servicio usó 2.37 s. Cuando el sistema se ejecuta en un solo núcleo, un uso de tiempo de CPU de 2.37 segundos corresponde al uso del 23.7% de ese núcleo. Para obtener más información, consulta la sección sobre tipos de perfiles disponibles.

Modifica la aplicación

Paso 1: ¿Qué función requiere mucho tiempo de CPU?

Una forma de identificar el código que podría estar optimizado es ver la tabla de funciones y las funciones voraces:

Para ver la tabla, haz clic en Lista de funciones de enfoque.
Ordena la tabla por Total. La columna Total muestra el uso de tiempo de CPU de una función y sus elementos secundarios.
En este ejemplo, GetMatchCount es la primera función shakesapp/server.go que aparece en la lista. Esa función usó 1.7 s de tiempo total de CPU o el 72% del tiempo total de CPU. Se sabe que esta función maneja las solicitudes de gRPC.

En el gráfico tipo llama, se muestra que la función GetMatchCount de shakesapp/server.go llama a MatchString que, a su vez, pasa la mayor parte de su tiempo llamando a Compile:

Paso 2: ¿Cómo puedes usar lo que aprendiste?

Confía en tu experiencia en lenguajes. MatchString es un método de expresión regular. Sabes que el procesamiento de expresiones regulares es muy flexible, pero no necesariamente la solución más eficiente para cada problema.
Confía en tu experiencia con la aplicación. El cliente está generando una palabra o frase, y el servidor está buscando esta frase.
Busca la implementación del método GetMatchCount de shakesapp/server.go para los usos de MatchString y, luego, determina si una función más simple y eficiente podría reemplazar esa llamada.

Paso 3: ¿Cómo puedes cambiar la aplicación?

En el archivo shakesapp/server.go, el código existente contiene una llamada a MatchString:

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

Una opción es reemplazar la lógica MatchString por una lógica equivalente que use strings.Contains:

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

Asegúrate de quitar la instrucción de importación para el paquete regexp.

Evalúa el cambio

Para evaluar el cambio, haz lo siguiente:

Ejecuta la aplicación con la versión de la aplicación establecida en 2:
```
go run . -version 2 -num_rounds 40
```
Más adelante, se muestra que, con la optimización, el tiempo que lleva ejecutar una sola ronda es mucho menor que el de la aplicación sin modificar. A fin de garantizar que la aplicación se ejecute lo suficiente para recopilar y subir perfiles, aumenta la cantidad de rondas.
Espera a que se complete la aplicación y, luego, visualiza los datos de perfil de esta versión de la aplicación:
- Haz clic en AHORA para cargar los datos de perfil más recientes. Para obtener más información, consulta Intervalo de tiempo.
- En el menú Versión, selecciona 2.

Para un ejemplo, el gráfico tipo llama es el siguiente:

Gráfico tipo llama que muestra el uso del tiempo de CPU de la versión 2.

En esta figura, el marco raíz se muestra como un valor de 7.8 s. Como resultado de cambiar la función de coincidencia de strings, el tiempo de CPU que usó la aplicación aumentó de 2.37 segundos a 7.8 segundos, o la aplicación pasó de usar el 23.7% de un núcleo de CPU al usar el 78% de un núcleo de CPU.

El ancho del marco es una medida proporcional del uso del tiempo de CPU. En este ejemplo, el ancho del marco para GetMatchCount indica que la función usa aproximadamente el 49% de todo el tiempo de CPU que usa la aplicación. En el gráfico tipo llama original, este mismo marco era de aproximadamente el 72% del ancho del gráfico. Para ver el uso exacto del tiempo de CPU, puedes usar la información sobre la herramienta de marcos o usar la Lista de funciones de enfoque:

Lista de funciones de enfoque que muestra el uso de tiempo de CPU de la versión 2.

El resultado en Cloud Shell muestra que la versión modificada completa alrededor de 5.8 solicitudes por segundo:

$ 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

El pequeño cambio en la aplicación tuvo dos efectos diferentes:

La cantidad de solicitudes por segundo aumentó de menos de 1 por segundo a 5.8 por segundo.
El tiempo de CPU por solicitud, que se calcula dividiendo el uso de CPU por la cantidad de solicitudes por segundo, disminuyó del 23,7% al 13,4%.

Ten en cuenta que el tiempo de CPU por solicitud disminuyó a pesar de que el uso de tiempo de CPU aumentó de 2.37 segundos, lo que corresponde a un 23.7% de uso de un solo núcleo de CPU, a 7.8 segundos o al 78% de un núcleo de CPU.

Usa perfiles de montón asignados para mejorar el uso de recursos

En esta sección, se ilustra cómo puedes usar el montón y los perfiles de montón asignados para identificar un método de asignación intensiva en la aplicación:

Los perfiles de montón muestran la cantidad de memoria asignada en el montón del programa en el instante en que se recopila el perfil.
Los perfiles de montón asignados muestran la cantidad total de memoria que se asignó en el montón del programa durante el intervalo en el que se recopiló el perfil. Si divides estos valores por 10 segundos, el intervalo de recopilación de perfil, puedes interpretarlos como tasas de asignación.

Habilita la recopilación de perfiles de montón

Ejecuta la aplicación con la versión de la aplicación configurada en 3 y habilita la recopilación de montón y perfiles de montón asignados.
```
go run . -version 3 -num_rounds 40 -heap -heap_alloc
```
Espera a que se complete la aplicación y, luego, visualiza los datos de perfil de esta versión de la aplicación:
- Haz clic en AHORA para cargar los datos de perfil más recientes.
- En el menú Versión, selecciona 3.
- En el menú Tipo de generador de perfiles, selecciona Montón asignado.
Para un ejemplo, el gráfico tipo llama es el siguiente:

Identifica la tasa de asignación de montón

El marco raíz muestra la cantidad total de montón que se asignó durante los 10 segundos en los que se recopiló un perfil, en promedio según todos los perfiles. En este ejemplo, el marco raíz muestra que, en promedio, se asignaron 1,535 GiB de memoria.

Modifica la aplicación

Paso 1: ¿Vale la pena minimizar la tasa de asignación de montón?

El uso de tiempo de CPU de la función de recopilación de elementos no utilizados de segundo plano de Go, runtime.gcBgMarkWorker.*, se puede usar para determinar si vale la pena optimizar una aplicación para reducir los costos de recopilación de elementos no utilizados:

Omite la optimización si el uso del tiempo de CPU es inferior al 5%.
Optimiza si el uso de tiempo de CPU es, al menos, de un 25%.

Para este ejemplo, el uso de CPU del recolector de elementos no usados en segundo plano es del 16.8%. Este valor es lo suficientemente alto como para intentar optimizar shakesapp/server.go:

Uso de tiempo de CPU del proceso de recopilación de elementos no utilizados en segundo plano para la versión 3.

Paso 2: ¿Qué función asigna mucha memoria?

El archivo shakesapp/server.go contiene dos funciones que pueden ser objetivos de optimización: GetMatchCount y readFiles. A fin de determinar la velocidad de asignación de memoria para estas funciones, configura el Tipo de perfil como Montón asignado y, luego, usa la Lista de funciones de enfoque .

En este ejemplo, la asignación de montón total para readFiles.func1 durante la recopilación de perfiles de 10 segundos es, en promedio, de 1,045 GiB o del 68% de la memoria total asignada. La asignación de montón individual durante la recopilación de perfiles de 10 segundos es de 255.4 MiB:

Lista de funciones de enfoque que muestra datos asignados del perfil de montón para la versión 3.

En este ejemplo, el método Go makeSlice asignó 779.7 MiB durante la colección de perfil de 10 segundos, en promedio. La forma más simple de reducir estas asignaciones es reducir las llamadas a makeSlice. La función readFiles llama a makeSlice a través de un método de biblioteca.

El resultado de este análisis sugiere que es posible reducir la tasa de asignaciones de montón mediante la optimización de readFiles.

Paso 3: ¿Cómo puedes cambiar la aplicación?

Una opción es modificar la aplicación para leer los archivos una vez y, luego, volver a usar ese contenido. Por ejemplo, puedes realizar los siguientes cambios:

Define una variable global files para almacenar los resultados de la lectura del archivo inicial:
```
var files []string
```

Modifica readFiles para que se muestre de forma anticipada cuando se defina files:

       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
                
        }

Evalúa el cambio

Para evaluar el cambio, haz lo siguiente:

Ejecuta la aplicación con la versión de la aplicación establecida en 4:
```
go run . -version 4 -num_rounds 60 -heap -heap_alloc
```
Espera a que se complete la aplicación y, luego, visualiza los datos de perfil de esta versión de la aplicación:
- Haz clic en AHORA para cargar los datos de perfil más recientes.
- En el menú Versión, selecciona 4.
- En el menú Tipo de generador de perfiles, selecciona Montón asignado.
Para cuantificar el efecto del cambio de readFiles en la tasa de asignación de montón, compara los perfiles de montón asignados para la versión 4 con los recopilados para 3:

La información sobre la herramienta de marco raíz muestra que, con la versión 4, la cantidad promedio de memoria asignada durante la recopilación de perfiles disminuyó 1,301 GiB, en comparación con la versión 3. La información sobre la herramienta para readFiles.func1 muestra una disminución de 1,045 GiB:
Para cuantificar el efecto en la recopilación de elementos no utilizados, configura una comparación de los perfiles de tiempo de CPU. En la siguiente captura de pantalla, se aplica un filtro a fin de mostrar las pilas para la recopilación de elementos no utilizados de Go runtime.gcBgMarkWorker.*. La captura de pantalla muestra que el uso de CPU para la recopilación de elementos no utilizados pasó del 16.8% al 4.97%.

Para determinar si hay un impacto en el cambio en el número de solicitudes por segundo manejadas por la aplicación, consulta el resultado en Cloud Shell. En este ejemplo, la versión 4 completa hasta 15 solicitudes por segundo, que es mucho más alta que las 5.8 solicitudes por segundo de la versión 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
...

El aumento en las consultas por segundo que entrega la aplicación podría deberse a que se dedicó menos tiempo a la recopilación de elementos no utilizados.

Puedes obtener una comprensión más completa del efecto de la modificación en readFiles si ves los perfiles de montón. Una comparación de los perfiles de montón para la versión 4 con la versión 3 muestra que el uso de montón disminuyó a 18.47 MiB de 70.95 MiB:

Resumen

En esta guía de inicio rápido, se usaron el tiempo de CPU y los perfiles de montón asignados para identificar posibles optimizaciones en una aplicación. Los objetivos eran maximizar la cantidad de solicitudes por segundo y eliminar las asignaciones innecesarias.

Mediante los perfiles de tiempo de CPU, se identificó una función que consume mucha CPU. Después de aplicar un cambio simple, la tasa de solicitudes del servidor aumentó a 5.8 por segundo, hasta cerca de 1 por segundo.
Mediante el uso de perfiles de montón asignados, la función shakesapp/server.go readFiles se identificó como que tiene una tasa de asignación alta. Después de optimizar readFiles, la tasa de solicitudes del servidor aumentó a 15 solicitudes por segundo y la cantidad promedio de memoria asignada durante la recopilación de perfiles de 10 segundos disminuyó en 1,301 GiB.

¿Qué sigue?

Para obtener información sobre cómo se recopilan y envían los perfiles a tu proyecto de Google Cloud, consulta la sección sobre colección de perfiles.
Lee nuestros recursos sobre DevOps y explora nuestro programa de investigación.

Para obtener información sobre cómo ejecutar el agente de Cloud Profiler, consulta: