Prácticas recomendadas de rendimiento

Árbol de decisión de optimización y cuándo dejar de ajustar.

Aplica estas reglas en revisiones de diseño, postmortems de incidentes y PRs de optimización para que el equipo mida primero, cambie una variable a la vez y se detenga cuando se cumplan los SLOs.

Cómo usar esta lista

• Requiere evidencia de perfil o benchmark antes de fusionar reescrituras de rutas críticas.
• Recorre los niveles A a D en orden durante los incidentes; no saltes a las perillas de GC.
• Codifica los elementos del Nivel A en las plantillas de servicio (administración de pprof, tiempos de espera, CI de benchmark).
• Empareja cada cambio de ajuste con valores de reversión y paneles de SLI.

A - Medir antes de cambiar el código

• Reproduce con cargas de tamaño de producción y concurrencia. Las entradas sintéticas pequeñas ocultan los costos reales de asignación y bloqueo.
• Captura perfiles de CPU y heap bajo carga, no en pods inactivos. Los perfiles vacíos desperdician tiempo de investigación.
• Adjunta la salida de go test -bench / benchstat para cambios en bibliotecas. Las micro-afirmaciones necesitan micro-pruebas.
• Registra la versión de Go, GOMAXPROCS y la configuración del generador de carga en los PRs. Los números sin contexto no son reproducibles.
• Compara un cambio a la vez. Las refactorizaciones mixtas hacen imposible la atribución.

B - Solucionar el cuello de botella correcto

• Lee el tiempo plano de CPU en tu módulo antes de editar los wrappers de la biblioteca estándar. El tiempo acumulado en net/http suele ser tu manejador.
• Empareja perfiles de CPU con alloc_space de heap cuando la GC o la latencia de cola importan. La rotación de asignaciones impulsa la frecuencia de las pausas.
• Usa el rastreo de ejecución cuando la CPU es baja pero la latencia es alta. El programador, las llamadas al sistema y las esperas STW aparecen en la línea de tiempo.
• Soluciona problemas de E/S, agrupación y contención antes de optimizar bucles hash. La red y los bloqueos dominan muchos servicios.
• Ejecuta el análisis de escape (-gcflags=-m) cuando benchmem muestra asignaciones sorprendentes. Los hechos del compilador superan las suposiciones.

C - Escribir rutas críticas conscientes de las asignaciones

• Pre-dimensiona slices y mapas cuando la longitud está limitada. make([]T, 0, n) y las sugerencias de mapas reducen las copias de crecimiento.
• Construye cadenas con strings.Builder en bucles. Evita la concatenación += en middleware críticos.
• Prefiere la semántica de valor para estructuras pequeñas cuando las API lo permiten. Los punteros innecesarios aumentan el trabajo de escaneo de la GC.
• Introduce sync.Pool solo después de obtener ganancias medibles en asignaciones. Los pools añaden complejidad y riesgo de estado obsoleto.
• Transmite respuestas en lugar de almacenar en búfer grandes []byte. Los picos de memoria se convierten en eventos de GC bajo carga.

D - Compilador, PGO y GC (últimos recursos)

• Actualiza default.pgo en los trenes de lanzamiento para obtener binarios estables limitados por CPU. Los perfiles obsoletos engañan al compilador.
• Establece GOMEMLIMIT cerca de los límites de memoria del pod antes de que se repitan los incidentes OOM. El límite suave activa la GC antes, no una capacidad mágica.
• Ajusta GOGC en canarios con p99 y barreras de protección de CPU. Documenta las variables de entorno de reversión en el manual de operaciones.
• Vuelve a evaluar después de las actualizaciones de la cadena de herramientas de Go. La GC Green Tea y las reglas de inlining evolucionan entre lanzamientos.
• Deja de ajustar cuando los SLOs estén en verde y los cambios adicionales perjudiquen la claridad. Registra la decisión de detener en el PR.

E - Higiene de servicio y operaciones

• Expón pprof solo en localhost o en puertos de administración autenticados. /debug/pprof público es un riesgo de seguridad y DoS.
• Establece tiempos de espera del cliente HTTP y reutiliza Transport por cada upstream. http.DefaultClient no tiene tiempo de espera.
• Alinea GOMAXPROCS con la cuota de CPU del contenedor. La latencia de la cola ejecutable aparece en los rastreos cuando no coinciden.
• Rastrea las regresiones de rendimiento en las pruebas de carga de staging. Detecta regresiones de asignación antes de los despliegues en producción.
• Trata unsafe y //go:noinline como excepciones revisadas. Requiere evidencia de ADR o benchmark.

Cuando hayas terminado

Los niveles A a C deben cumplirse antes de que los experimentos del Nivel D se envíen a producción.

Si la latencia p99, la tasa de error y las métricas de costo cumplen los SLOs acordados, pospón la optimización adicional hasta la próxima regresión medida.

La claridad gana la revisión por defecto a menos que la evidencia muestre una excepción de ruta crítica.

Preguntas frecuentes

Relacionado

• Rendimiento en Go: Medir, Perfilar, Luego Optimizar - resumen de la sección
• Conceptos básicos de rendimiento - ejemplos iniciales ejecutables
• Perfilado de CPU y Heap con pprof - recopilación de evidencia
• Reglas de rendimiento: Cuándo optimizar - hoja de trucos de política
• Ajuste de GC para servicios sensibles a la latencia - experimentos controlados de GC

Enlaces externos relacionados

• Effective Go - Guía oficial para escribir Go claro e idiomático.
• Go Blog (Oficial) - Anuncios oficiales, análisis profundos y notas de lanzamiento.
• pkg.go.dev - Documentación oficial de paquetes y sitio de descubrimiento.
• Concurrency in Go - Katherine Cox-Buday.
• Learning Go (2nd Edition) - Jon Bodner.

Versiones de pila: Esta página fue escrita para Go 1.26.x (Green Tea GC por defecto, go fix modernizers - verifica el parche en la compilación), chi (última versión - verifica en la compilación), gin (última versión - verifica en la compilación), echo (última versión - verifica en la compilación), google.golang.org/grpc (última versión - verifica en la compilación), sigs.k8s.io/controller-runtime (última versión - verifica en la compilación), kubebuilder (última versión - verifica en la compilación), tinygo (última versión - verifica los objetivos de la placa en la compilación), wazero (última versión - verifica en la compilación) y golangci-lint (última versión - verifica el conjunto de linters en la compilación).