Load Testing Strategies for Web Applications: Find Breaking Points Before Users Do

El 80 % de los problemas de rendimiento los descubren los usuarios finales, no las pruebas. Las pruebas de carga invierten esta proporción al simular patrones de tráfico del mundo real en su aplicación antes de que los usuarios encuentren problemas. The difference between a site that handles Black Friday traffic and one that crashes is almost always whether someone ran a load test first.

Esta guía cubre la metodología de pruebas de carga, la selección de herramientas, el diseño de pruebas y la interpretación de resultados para aplicaciones web, plataformas de comercio electrónico y sistemas ERP.

Conclusiones clave

• Load testing should simulate realistic user behavior, not just hammer a single endpoint
• Establish performance baselines before optimizing --- you cannot improve what you have not measured
• Run load tests in a production-like environment; staging results may not reflect production behavior
• Automate load tests in CI/CD to catch performance regressions before deployment

---

Tipos de pruebas de carga

---

Prueba de carga con k6

Prueba de carga básica

// k6/load-test.js
import http from 'k6/http';
import { check, sleep } from 'k6';

export const options = {
  stages: [
    { duration: '2m', target: 50 },   // Ramp up to 50 users
    { duration: '5m', target: 50 },   // Stay at 50 users
    { duration: '2m', target: 100 },  // Ramp up to 100 users
    { duration: '5m', target: 100 },  // Stay at 100 users
    { duration: '2m', target: 0 },    // Ramp down
  ],
  thresholds: {
    http_req_duration: ['p(95)<500', 'p(99)<1000'],
    http_req_failed: ['rate<0.01'],
    http_reqs: ['rate>100'],
  },
};

export default function () {
  // Simulate realistic user behavior
  const homeResponse = http.get('https://example.com/');
  check(homeResponse, {
    'homepage status is 200': (r) => r.status === 200,
    'homepage loads in under 1s': (r) => r.timings.duration < 1000,
  });
  sleep(Math.random() * 3 + 1); // 1-4 seconds think time

  const productsResponse = http.get('https://example.com/api/v1/products');
  check(productsResponse, {
    'products API is 200': (r) => r.status === 200,
    'products API under 500ms': (r) => r.timings.duration < 500,
  });
  sleep(Math.random() * 2 + 1);
}

Prueba de recorrido del usuario de comercio electrónico

// k6/ecommerce-journey.js
import http from 'k6/http';
import { check, group, sleep } from 'k6';

export const options = {
  scenarios: {
    browsing: {
      executor: 'ramping-vus',
      startVUs: 0,
      stages: [
        { duration: '5m', target: 200 },
        { duration: '10m', target: 200 },
        { duration: '5m', target: 0 },
      ],
      exec: 'browsingScenario',
    },
    purchasing: {
      executor: 'ramping-vus',
      startVUs: 0,
      stages: [
        { duration: '5m', target: 20 },
        { duration: '10m', target: 20 },
        { duration: '5m', target: 0 },
      ],
      exec: 'purchaseScenario',
    },
  },
  thresholds: {
    'http_req_duration{scenario:browsing}': ['p(95)<800'],
    'http_req_duration{scenario:purchasing}': ['p(95)<2000'],
    http_req_failed: ['rate<0.01'],
  },
};

export function browsingScenario() {
  group('Browse Products', () => {
    http.get('https://store.example.com/');
    sleep(2);
    http.get('https://store.example.com/products');
    sleep(3);
    http.get('https://store.example.com/products/sample-product');
    sleep(2);
  });
}

export function purchaseScenario() {
  group('Purchase Flow', () => {
    // Browse
    http.get('https://store.example.com/products/sample-product');
    sleep(1);

    // Add to cart
    http.post('https://store.example.com/api/cart', JSON.stringify({
      productId: 'prod_123',
      quantity: 1,
    }), { headers: { 'Content-Type': 'application/json' } });
    sleep(2);

    // Checkout
    http.get('https://store.example.com/cart');
    sleep(3);

    // Place order (simulated)
    const orderResponse = http.post('https://store.example.com/api/checkout/validate', JSON.stringify({
      email: `test-${__VU}@example.com`,
    }), { headers: { 'Content-Type': 'application/json' } });

    check(orderResponse, {
      'checkout validates': (r) => r.status === 200 || r.status === 201,
    });
    sleep(1);
  });
}

Prueba de estrés (encontrar el punto de ruptura)

// k6/stress-test.js
import http from 'k6/http';
import { check } from 'k6';

export const options = {
  stages: [
    { duration: '2m', target: 100 },
    { duration: '5m', target: 100 },
    { duration: '2m', target: 200 },
    { duration: '5m', target: 200 },
    { duration: '2m', target: 500 },
    { duration: '5m', target: 500 },
    { duration: '2m', target: 1000 },
    { duration: '5m', target: 1000 },
    { duration: '5m', target: 0 },
  ],
};

export default function () {
  const res = http.get('https://example.com/api/v1/products');
  check(res, {
    'status is 200': (r) => r.status === 200,
  });
}

---

Interpretación de resultados

Métricas clave

Patrones de cuellos de botella comunes

CPU-bound bottleneck: Response time increases linearly with load. P95 y P99 divergen lentamente.

• Fix: Optimize hot code paths, add CPU capacity, or scale horizontally

Database bottleneck: Response time increases exponentially at a specific load threshold. Agotamiento del grupo de conexiones.

• Fix: Query optimization, connection pooling, read replicas (see database scaling guide)

Memory bottleneck: Gradual degradation over time. Las pausas de GC provocan picos de latencia.

• Fix: Increase memory, fix memory leaks, optimize object allocation

Network bottleneck: Response time increases uniformly across all endpoints. Saturación de ancho de banda.

• Fix: CDN for static assets, compression, reduce payload sizes

---

Líneas base de desempeño

Estableciendo una línea de base

Antes de optimizar, documente su rendimiento actual:

# Run baseline test
k6 run --out json=baseline-results.json k6/load-test.js

# Compare after optimization
k6 run --out json=optimized-results.json k6/load-test.js

Presupuesto de rendimiento

Defina el rendimiento aceptable para cada punto final:

---

Integración CI/CD

Pruebas de regresión de rendimiento automatizadas

# .github/workflows/performance.yml
name: Performance Test
on:
  push:
    branches: [main]

jobs:
  load-test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Run k6 load test
        uses: grafana/[email protected]
        with:
          filename: k6/load-test.js
          flags: --out json=results.json
        env:
          K6_TARGET_URL: ${{ secrets.STAGING_URL }}

      - name: Check thresholds
        run: |
          if grep -q '"thresholds":{".*":"fail"' results.json; then
            echo "Performance thresholds exceeded!"
            exit 1
          fi

---

Lista de verificación de pruebas de carga

Antes de realizar la prueba

• [] El entorno coincide con la producción (tipos de instancia, tamaño de la base de datos)
• [] Los datos de prueba son representativos (recuento de productos realista, recuento de usuarios)
• [] La supervisión está activa (sigue las métricas del servidor durante la prueba)
• [] Se notifica a las partes interesadas (las pruebas de carga pueden activar alertas)
• [] CDN y almacenamiento en caché están configurados como en producción.

Durante la prueba

• [] Supervisar la CPU del servidor, la memoria y la E/S del disco.
• [] Monitorear conexiones de bases de datos y latencia de consultas
• [] Esté atento a los aumentos en la tasa de error
• [] Verificar el agotamiento de los recursos (descriptores de archivos, conexiones)
• [] Tenga en cuenta el nivel de carga donde el rendimiento se degrada

Después de la prueba

• Documentar los resultados de referencia
• Identificar cuellos de botella y sus umbrales de carga
• [] Crear tickets para mejoras de rendimiento
• [] Comparar con el presupuesto de rendimiento
• [] Programar prueba de seguimiento después de las optimizaciones

---

Preguntas frecuentes

¿Deberíamos cargar la producción o la puesta en escena de la prueba?

Ambos, si es posible. Preparación para pruebas periódicas e integración de CI/CD. Producción para validación periódica (durante horas de poco tráfico) porque la preparación a menudo difiere en el tamaño de la base de datos, la calidez de la caché, la configuración de CDN y la topología de la red. Si solo puede probar un entorno, pruebe la preparación, pero hágalo lo más parecido a una producción posible.

¿Con qué frecuencia debemos ejecutar pruebas de carga?

Pruebas de humo en cada implementación (automatizadas en CI/CD). Pruebas de carga completa semanalmente o antes de lanzamientos importantes. Pruebas de estrés trimestrales o antes de eventos conocidos de alto tráfico (ventas, lanzamientos). Pruebas de remojo trimestralmente para detectar pérdidas de memoria y degradación a largo plazo.

¿Cómo realizamos pruebas de carga en un sistema ERP?

Las pruebas de carga de ERP requieren simular usuarios simultáneos que realizan diferentes tareas: generar facturas, crear órdenes de compra, ejecutar informes e importar datos. Céntrese en las operaciones más pesadas (generación de informes, importación de datos) y en las operaciones más concurrentes (entrada de pedidos durante las horas pico). ECOSIRE proporciona pruebas de rendimiento de Odoo como parte de nuestros servicios de soporte.

¿Cuál es un tiempo de reflexión realista entre solicitudes?

Para navegación de comercio electrónico: 2-5 segundos. Para completar formularios: 10-30 segundos. Para pagar: 15-60 segundos. Para uso de administrador/ERP: 5-15 segundos. Agregue siempre tiempo de reflexión aleatorio a sus pruebas de carga: los intervalos constantes crean patrones de carga sincronizados poco realistas.

---

¿Qué viene después?

Las pruebas de carga revelan cuellos de botella que guían sus esfuerzos de optimización. Realice un seguimiento con escalado de base de datos para cuellos de botella en la base de datos, optimización de CDN para entrega de activos estáticos y escalado automático para capacidad elástica.

Comuníquese con ECOSIRE para realizar pruebas y optimización del rendimiento, o explore nuestra guía DevOps para conocer la estrategia de infraestructura completa.

---

Publicado por ECOSIRE: ayuda a las empresas a crear aplicaciones que funcionan bajo presión.