Pruebas de Carga: Lista de Verificación y Fallos

Un Enfoque Sistemático para Pruebas de Carga: Desde Fallos de Tokens hasta Métricas Estables

El backend, actuando como proxy entre el frontend y un servicio externo, almacenaba en caché un token de acceso mediante opcache. Bajo carga, varias solicitudes paralelas detectaron simultáneamente un token caducado e intentaron renovarlo. El token antiguo sobrescribió el nuevo en la caché, provocando errores 403.

Solución: Añadimos un bloqueo para la renovación del token y trasladamos la caché a memcached en clúster para un estado unificado entre procesos. Las pruebas en Postman con solicitudes paralelas confirmaron que se eliminó la condición de carrera.

Métricas antes: El tiempo de respuesta crecía exponencialmente, la tasa de éxito caía por debajo del 90% a 300 RPS. Después: Tasa de éxito 100%, errores 5xx <0.05%, tiempo de respuesta promedio 99-104 ms a 226 RPS.

Preparación del Backend: Lista de Verificación de Optimización

Antes de las pruebas de carga (LT), un desarrollador backend sigue una lista de verificación sistemática. Esto minimiza los cuellos de botella a nivel de código e infraestructura.

Optimización de Base de Datos

• Indexar todos los campos en cláusulas WHERE y JOIN.
• Analizar EXPLAIN para consultas lentas.
• Replicación maestro-esclavo, agrupación de conexiones (ej., pgbouncer o equivalente).

Caché

• Memcached para datos repetitivos.
• Caché de respuestas HTTP en Varnish o nginx.
• Caché de plantillas Twig.

Procesamiento Asíncrono

• Colas RabbitMQ o Redis para tareas en segundo plano.
• Delegar envío de correos, generación de PDF a trabajos en segundo plano.

Código PHP

• Eliminar consultas N+1.
• Optimizar bucles, evitar recursividad profunda.
• Liberar memoria con unset() para objetos grandes.

Infraestructura

• php-fpm: pm.max_children > 100, pm.max_requests = 500.
• MinIO para almacenamiento de archivos.
• HPA en Kubernetes basado en CPU/RAM.
• Limitador de tasa (nginx o Traefik) para regulación.

Frontend: Reduciendo la Carga Entrante

El frontend genera el tráfico principal. Las optimizaciones aquí pueden reducir el RPS del backend en un 30-50%.

• Recursos estáticos: caché nginx para JS/CSS/imágenes.
• Caché de API en cliente: localStorage o memcached para datos que cambian poco (ej., catálogos, configuraciones).
• Paginación: Usar limit/offset o scroll infinito en lugar de cargas completas de datos.
• SSG/ISR: Next.js para renderizado de páginas estáticas.
• SSE/Webhooks: Reemplazar polling con notificaciones push.

Flujo de Trabajo de Pruebas de Carga

Las LT son obligatorias para funciones que cambian la lógica del servidor, caché o bases de datos. Realizarlas en staging/producción por la noche durante carga mínima de usuarios.

• Planificación (una semana antes): Líder + PM + DevOps estiman el RPS objetivo (N solicitudes/seg).
• Rol de DevOps: Configurar pods (CPU/RAM), HPA, monitorización en tiempo real.
• Ejecución: Usar k6 o similar, con escenarios para endpoints de API.
• Monitorización: Grafana (RPS, latencia, tasa de error), Graylog para logs.
• Análisis: Identificar puntos de degradación, corregir cuellos de botella, repetir.

Criterios de éxito: Tasa de éxito >99%, latencia <150 ms al RPS objetivo con un margen del 20%.

Conclusiones Clave

• Las condiciones de carrera en procesos (ej., tokens, sesiones) solo se revelan bajo carga paralela.
• Caché en clúster (memcached) en lugar de opcache local previene condiciones de carrera.
• LT en entornos similares a producción: replicación de base de datos, servicios externos.
• DevOps en el ciclo: Ajustar recursos dinámicamente durante las pruebas.
• Las optimizaciones de frontend reducen la carga más efectivamente que las correcciones de backend.

Métricas de Éxito y Puntos de Referencia

Ejemplo de Grafana después de las correcciones:

| Métrica | Promedio | Pico | Objetivo |

|---------|----------|------|----------|

| Tasa de Éxito | 100% | 100% | >99% |

| Errores 5xx | 0.017% | 0.042% | <0.1% |

| RPS | 226 | 321 | 300+ |

| Latencia (ms) | 99-104 | 123 | <150 |

Estabilización a 226 RPS sin degradación. Punto de fallo: ~450 RPS (100% de margen).

Recomendaciones para Desarrolladores Intermedios/Senior

• Integrar LT en CI/CD: pruebas automatizadas en fusión.
• Monitorizar latencia p99, no solo el promedio.
• Probar escenarios de peor caso: 80% del tráfico en un solo endpoint.
• Registrar IDs de solicitud para trazabilidad (ej., Jaeger/OpenTelemetry).

Este enfoque identifica problemas durante el desarrollo, reduciendo incidentes en producción.

— Editorial Team