Guía de optimización de rendimiento para aplicaciones Go

Guía de optimización de rendimiento para aplicaciones Go

• Recopilación de recursos técnicos para desarrollar aplicaciones Go de alto rendimiento
• Ofrece patrones prácticos, casos reales e insights de rendimiento de bajo nivel dirigidos a ingenieros que desarrollan APIs, microservicios y sistemas distribuidos de alto rendimiento
• Aunque Go no ofrece tantas opciones de ajuste de rendimiento como C++ o Rust, sí brinda varias oportunidades de optimización, como reutilización de memoria, control de asignaciones, networking eficiente y manejo de concurrencia
• Esta guía se enfoca en técnicas de mejora de rendimiento medibles, desde funciones clave del lenguaje hasta estrategias avanzadas de networking

Contenido cubierto hasta ahora

Patrones comunes de rendimiento en Go

• Primer artículo que organiza los patrones clave de rendimiento que todo desarrollador de Go debería conocer
• Temas principales:
  • Uso eficaz de sync.Pool
  • Evitar asignaciones de memoria innecesarias
  • Optimización del layout de structs y la alineación de memoria
  • Manejo eficiente de errores
  • Abstracción de costo cero mediante interfaces
  • Reutilización de slices y técnicas de ordenamiento in-place
• Está escrito con base en casos reales de trabajo e incluye benchmarks y ejemplos de código listos para copiar

Contenido próximo

Networking de alto rendimiento en Go

• Próximamente se publicará un análisis profundo sobre cómo construir servicios de red de alto rendimiento usando la biblioteca estándar y bibliotecas externas
• Temas a tratar:
  • Uso eficiente de net/http y net.Conn
  • Manejo de conexiones concurrentes a gran escala
  • Ajuste de rendimiento con epoll/kqueue, GOMAXPROCS, etc.
  • Técnicas de pruebas de carga y diagnóstico de cuellos de botella
  • Cuándo usar bibliotecas de red de bajo nivel como fasthttp y cómo equilibrarlo con la mantenibilidad

Público objetivo

• Ingenieros backend que optimizan servicios Go en producción
• Desarrolladores que trabajan con sistemas sensibles a la latencia
• Equipos que están migrando a Go o construyendo rutas de alto rendimiento
• Desarrolladores interesados en el modelo de rendimiento y los trade-offs de Go

[GN⁺]

Opiniones de Hacker News

• Al ver el primer ejemplo del pool de objetos, sorprende que sea posible sin advertencia

  • Esta API existía antes de los genéricos, por eso usa any
  • Aunque Go en principio tiene un sistema de tipos fuerte, en la práctica hay muchas API que se salen del sistema de tipos
  • Esto hace preguntarse si el sistema de tipos realmente es tan útil
  • También llama la atención que no exista una API para restablecer valores a su valor predeterminado inicializado

• La guía de rendimiento recomienda minimizar las asignaciones para reducir el tiempo del GC

  • La fase de marcado del GC consume tiempo, y conviene evitar asignaciones de larga vida
  • Las asignaciones de corta vida casi no afectan el tiempo del GC
  • En aplicaciones reales es casi imposible evitar el GC, y resulta más efectivo reducir el tiempo de marcado del GC

• Además...

  • Guía de optimización de Go
  • Guía de Go de Uber
  • Al cambiar entre proyectos en varios lenguajes durante 6 meses, es difícil recordar las cosas importantes

• El zero-copy está subestimado

  • Las interfaces de Go son adecuadas para escribir código zero-copy, pero hay que tener cuidado
  • A menudo uno se da cuenta de cuánto tiempo se va en asignar y mover memoria

• GOMEMLIMIT ha ayudado varias veces

  • Es útil en producción contenerizada y resolvió problemas de falta de memoria en CI
  • Al cambiar a nogo, se resolvieron los problemas de golangci-lint

• Da curiosidad qué tipo de proyectos necesitan optimización

  • Por ejemplo: alineación de campos en structs

• Al ver la documentación de object pooling, surge la duda de si hay planes de hacer genéricos paquetes como sync

• Sorprende que Go sea parecido a C en la alineación de structs

• "El struct Data contiene un arreglo [1024]int, lo que equivale a 4 KB"

  • Hace preguntarse si alguien sigue usando arquitecturas de 32 bits como predeterminadas

• Puedes engañarte a ti mismo usando sync.Pool

  • pprof se ve bien en benchmarks porque no hay asignaciones, pero el uso real de memoria aumenta
  • Lo importante es medir el beneficio en el mundo real