Validar plan de pruebas de carga con Azure Load Testing (App Service + Container App + PostgreSQL Flexible) y cómo configurar la carga

Hola @Alejandro Jimenez Gonzalez ,

Gracias por ponerse en contacto con Microsoft Q&A.

Tu enfoque es en general correcto y coincide con la forma en la que validaría la capacidad para un evento estacional.

1. Pruebas basadas en URL vs JMeter Para endpoints que incluyen login, autenticación, sesiones y escrituras en base de datos, recomendaría usar JMeter. Las pruebas basadas solo en URLs son útiles para escenarios simples (GET/APIs), pero JMeter es más adecuado para simular flujos reales de usuarios, manejo de tokens, cookies y procesos multi-etapa.

2. Pruebas en P2v3 Sí, escalar el App Service de B1 a P2v3 durante la prueba es la estrategia correcta. Azure cobra de forma prorrateada, por lo que solo pagas el tiempo en que el nivel superior está activo. Si producción usará P2v3 con la misma configuración de la aplicación, los resultados serán representativos del comportamiento real.

3. Configuración de carga para 300–400 usuarios concurrentes En lugar de comenzar directamente con 400 usuarios, es mejor hacer una subida progresiva, por ejemplo:

• 100 usuarios durante 10 minutos
• 200 usuarios durante 10 minutos
• 300 usuarios durante 10 minutos
• 400 usuarios durante 10–15 minutos

Opcionalmente una etapa de 500 usuarios para identificar el punto de ruptura

Se deben monitorear los tiempos de respuesta (p95), el throughput y las tasas de error. El límite real suele estar donde la latencia o los errores dejan de ser aceptables, no necesariamente cuando el sistema falla por completo.

4. Indicadores de cuello de botella en PostgreSQL B1ms Para determinar si PostgreSQL es el limitante, monitorea:

• CPU %
• Créditos de CPU restantes
• Conexiones activas
• IOPS de lectura/escritura
• Latencia de almacenamiento
• Consultas lentas y bloqueos

Si los créditos de CPU se agotan, el CPU se mantiene alto de forma sostenida, las conexiones se saturan o la latencia de almacenamiento aumenta antes de que la capa de aplicación se sature, es una señal clara de que deberías migrar a General Purpose.

5. Visibilidad del escalado del Container App Durante la prueba, monitorea:

• Número de réplicas
• Uso de CPU
• Uso de memoria

Deberías poder ver cómo el Container App escala desde 1 réplica hasta el máximo configurado (por ejemplo, 5) conforme aumenta la carga. Esto ayuda a validar tanto el rendimiento como el comportamiento del autoscaling.

6. Pruebas de escritura sin enviar correos ni generar datos no deseados Durante las pruebas de carga, desactivaría el envío real de correos (por ejemplo usando el driver log o array en Laravel, o un servidor SMTP simulado). Para las escrituras en base de datos, usaría datos parametrizados (CSV en JMeter), etiquetaría los registros con un identificador de ejecución de prueba y luego los limpiaría al finalizar. Esto permite pruebas realistas sin afectar sistemas externos ni dejar datos innecesarios.

7. Cobro de VUH El consumo de VUH en Azure Load Testing se basa en la ejecución real de la prueba. Si se detiene antes de tiempo, la facturación también se detiene; no se cobra por el tiempo no utilizado.

Evaluación general Probar en DEV mientras se escalan temporalmente los App Services a P2v3 es una estrategia práctica y rentable. Mantener PostgreSQL en Burstable inicialmente es razonable, siempre que se monitoricen cuidadosamente los créditos de CPU, conexiones e IOPS. Si la base de datos se convierte en el primer cuello de botella, conviene repetir la prueba con una capa General Purpose para validar el sistema completo. Con escenarios realistas en JMeter y una subida progresiva hasta 300-400 usuarios concurrentes, podrás identificar el verdadero límite del sistema y dimensionar correctamente la producción.

¡Espero que esto te ayude!

Si la solución fue útil, te agradeceríamos que dedicaras un momento a hacer clic en y luego en «Sí» en la pregunta «¿Le resultó útil esta respuesta?». Y si tienes alguna otra consulta, háznoslo saber.