El rendimiento de un servicio en Go depende de la carga de trabajo, el tamaño de los datos, las dependencias y el hardware. Las cifras de QPS y latencia solo son significativas con una descripción de prueba reproducible. Esta guía de planificación explica qué medir y cómo revisar una propuesta de optimización; no promete un rendimiento de procesamiento ni un tiempo de respuesta determinados.
Define la carga de trabajo antes que el objetivo
| Entrada | Registrar en el plan de pruebas | Por qué es importante |
|---|---|---|
| Tráfico | Mezcla de solicitudes, usuarios simultáneos, picos y duración de la prueba | Un único endpoint almacenado en caché no representa el producto |
| Datos | Tamaño del conjunto de datos, estructura de la consulta y estado de la caché | Los conjuntos de datos pequeños o en caché pueden ocultar los límites de la base de datos |
| Entorno | CPU, memoria, red y dependencias externas | Los resultados no pueden transferirse entre entornos sin cambios |
| Resultado | Latencia percentil, tasa de errores, rendimiento de procesamiento y uso de recursos | La latencia media oculta las solicitudes lentas y los fallos |
Mide el cuello de botella
Usa la creación de perfiles para examinar la CPU, las asignaciones y los bloqueos, y las trazas para seguir el tiempo empleado durante una solicitud. Las esperas de conexiones de base de datos, las consultas lentas y las API externas pueden dominar incluso cuando el uso de la CPU de la aplicación es bajo. La creación de perfiles genera sobrecarga, por lo que debes documentar su uso y comparar en condiciones coherentes. Consulta la guía oficial de diagnóstico de Go.
Aplica un cambio frente a la línea base
Entre los posibles cambios se incluyen la indexación de consultas, la concurrencia limitada, los plazos de contexto, el ajuste del grupo de conexiones o el almacenamiento en caché. Indica el mecanismo esperado, las reglas de invalidación y el comportamiento ante fallos. Compara cada cambio con la línea base usando la misma carga de trabajo; conserva un cambio solo cuando el comportamiento y el rendimiento previstos mejoren conjuntamente.
Solicita una revisión del rendimiento del backend
Prepara los endpoints afectados, el tráfico observado, muestras de latencia y errores, el tamaño de la base de datos, los límites del alojamiento y cualquier método de prueba anterior. Elimina las credenciales y los datos personales de las trazas. Explora el desarrollo de backends y sistemas empresariales o envía un resumen para la revisión del rendimiento. Acuerda criterios de aceptación medibles y un plan de reversión antes de la implementación.