LINIA BASE (2026-04-10, rutas-norte-pre, 4 repliques d'api-reserves)

Peticions per segon sostingudes:        340 rps
Latencia p50:                            42 ms
Latencia p95:                           287 ms
Latencia p99:                           891 ms
Taxa d'error:                           0,02 %
CPU mitjana per replica:                310m de 412m (75 %)
Connexions actives a PostgreSQL:         78 de 200

// proves/carrega/pont-maig.js
import http from 'k6/http';
import { check, sleep, group } from 'k6';
import { Rate, Trend, Counter } from 'k6/metrics';

// ---------------------------------------------------------------------------
// METRIQUES PERSONALITZADES
// Les metriques de k6 per defecte mesuren peticions HTTP. Aquestes mesuren
// OPERACIONS DE NEGOCI, que es el que li importa a Rutas Norte.
// ---------------------------------------------------------------------------
const errorReserves = new Rate('errors_reserva');
const duracioCerca = new Trend('duracio_cerca_rutes', true);
const duracioReserva = new Trend('duracio_confirmar_reserva', true);
const reservesConfirmades = new Counter('reserves_confirmades');

// ---------------------------------------------------------------------------
// CONFIGURACIO DE L'ESCENARI
// ---------------------------------------------------------------------------
export const options = {
  scenarios: {
    // ESCENARI 1: l'allau de l'obertura de la venda.
    // Reprodueix el que passa el 25 d'abril a les 10:00.
    obertura_venda: {
      executor: 'ramping-arrival-rate',
      // ramping-arrival-rate mante una TAXA D'ARRIBADA constant,
      // independentment de si el sistema respon rapid o lent.
      // Es la diferencia critica amb ramping-vus: els usuaris reals NO
      // esperen que acabis d'atendre l'anterior per arribar.
      startRate: 20,
      timeUnit: '1s',
      preAllocatedVUs: 200,
      maxVUs: 3000,
      stages: [
        { duration: '2m',  target: 20   },  // Calma previa. Linia base.
        { duration: '40s', target: 500  },  // L'ALLAU: x25 en 40 segons
        { duration: '10m', target: 500  },  // Altiplà: dues hores comprimides
        { duration: '5m',  target: 120  },  // Descens gradual
        { duration: '3m',  target: 20   },  // Tornada a la calma
      ],
      gracefulStop: '30s',
    },
  },

  // ---------------------------------------------------------------------------
  // LLINDARS: si no es compleixen, k6 acaba amb codi d'error.
  // Aixo converteix la prova en alguna cosa que pot FALLAR en un pipeline de CI.
  // ---------------------------------------------------------------------------
  thresholds: {
    // L'SLO de Rutas Norte: p95 per sota de 300 ms.
    'http_req_duration': ['p(95)<300', 'p(99)<1000'],
    // Menys de l'1 % d'errors a les reserves. Es el que costa diners.
    'errors_reserva': ['rate<0.01'],
    // La cerca de rutes es l'operacio mes frequent: mes exigent.
    'duracio_cerca_rutes': ['p(95)<200'],
    // Confirmar una reserva escriu a PostgreSQL: se li permet mes.
    'duracio_confirmar_reserva': ['p(95)<800'],
    // Menys del 0,5 % de fallades HTTP en total.
    'http_req_failed': ['rate<0.005'],
  },
};

// ---------------------------------------------------------------------------
// DADES DE PROVA (fictícies)
// ---------------------------------------------------------------------------
const ORIGENS = ['BIL', 'SDR', 'OVD', 'GIJ', 'SAN', 'VIT', 'LOG', 'PAM'];
const DESTINS = ['MAD', 'BCN', 'ZAZ', 'VLC', 'SVQ', 'BIO', 'LCG'];

const BASE = __ENV.URL_BASE || 'http://api-reserves.rutas-norte-pre.svc.cluster.local';

function aleatori(llista) {
  return llista[Math.floor(Math.random() * llista.length)];
}

function dataPont() {
  // Les reserves del pont es concentren en tres dies concrets.
  const dies = ['2026-04-30', '2026-05-01', '2026-05-02', '2026-05-03'];
  return aleatori(dies);
}

// ---------------------------------------------------------------------------
// EL RECORREGUT DE L'USUARI
// Reprodueix el que fa una persona de veritat: cerca, mira, tria, confirma.
// ---------------------------------------------------------------------------
export default function () {
  const origen = aleatori(ORIGENS);
  const desti = aleatori(DESTINS);
  const data = dataPont();

  let idRuta = null;

  // PAS 1: cercar rutes. Es l'operacio MES FREQUENT (tothom cerca).
  group('01_cercar_rutes', function () {
    const inici = Date.now();
    const res = http.get(
      `${BASE}/rutes?origen=${origen}&desti=${desti}&data=${data}`,
      { tags: { operacio: 'cercar_rutes' } }
    );
    duracioCerca.add(Date.now() - inici);

    const ok = check(res, {
      'la cerca retorna 200': (r) => r.status === 200,
      'la cerca retorna rutes': (r) => {
        try {
          return JSON.parse(r.body).rutes !== undefined;
        } catch (e) {
          return false;
        }
      },
    });

    if (ok && res.status === 200) {
      try {
        const rutes = JSON.parse(res.body).rutes;
        if (rutes && rutes.length > 0) {
          idRuta = aleatori(rutes).id;
        }
      } catch (e) { /* cos malformat: es comptabilitza al check */ }
    }
  });

  // PAUSA: l'usuari mira els resultats. Entre 2 i 6 segons.
  // AQUEST SLEEP ES ESSENCIAL. Sense ell, la prova genera un patro de carrega
  // que no s'assembla en res al real, i les conclusions no valen.
  sleep(Math.random() * 4 + 2);

  if (!idRuta) {
    // No hi ha rutes per a aquesta combinacio. L'usuari se'n va. Es realista:
    // no tothom troba el que busca.
    return;
  }

  // PAS 2: consultar la disponibilitat de places.
  // Aquesta consulta HAURIA de servir-se des de redis-cache.
  group('02_consultar_places', function () {
    const res = http.get(
      `${BASE}/rutes/${idRuta}/places`,
      { tags: { operacio: 'consultar_places' } }
    );
    check(res, { 'places retorna 200': (r) => r.status === 200 });
  });

  sleep(Math.random() * 3 + 1);

  // PAS 3: confirmar la reserva.
  // Nomes el 18 % de les cerques acaben en reserva. Es la taxa de
  // conversio real de Rutas Norte, mesurada en produccio.
  if (Math.random() > 0.18) {
    return;
  }

  group('03_confirmar_reserva', function () {
    const inici = Date.now();
    const carrega = JSON.stringify({
      idRuta: idRuta,
      seient: Math.floor(Math.random() * 54) + 1,
      passatger: {
        nom: `Client Prova ${__VU}-${__ITER}`,
        document: `00000000${(__VU % 10)}X`,
        correu: `prova-${__VU}-${__ITER}@ejemplo.example`,
      },
    });

    const res = http.post(`${BASE}/reserves`, carrega, {
      headers: { 'Content-Type': 'application/json' },
      tags: { operacio: 'confirmar_reserva' },
    });

    duracioReserva.add(Date.now() - inici);

    const ok = check(res, {
      'la reserva retorna 201': (r) => r.status === 201,
      'la reserva retorna localitzador': (r) => {
        try {
          return JSON.parse(r.body).localitzador !== undefined;
        } catch (e) {
          return false;
        }
      },
    });

    errorReserves.add(!ok);
    if (ok) reservesConfirmades.add(1);
  });

  sleep(1);
}

// ---------------------------------------------------------------------------
// RESUM FINAL
// ---------------------------------------------------------------------------
export function handleSummary(data) {
  const m = data.metrics;
  const linia = (etiqueta, valor) => `  ${etiqueta.padEnd(38)} ${valor}\n`;

  let sortida = '\n=== PROVA DE CARREGA: PONT DE MAIG ===\n\n';
  sortida += linia('Peticions totals', m.http_reqs.values.count);
  sortida += linia('Peticions per segon (mitjana)', m.http_reqs.values.rate.toFixed(1));
  sortida += linia('Reserves confirmades', m.reserves_confirmades ? m.reserves_confirmades.values.count : 0);
  sortida += '\n  --- LATENCIA GLOBAL ---\n';
  sortida += linia('p50', m.http_req_duration.values['p(50)'].toFixed(1) + ' ms');
  sortida += linia('p95', m.http_req_duration.values['p(95)'].toFixed(1) + ' ms');
  sortida += linia('p99', m.http_req_duration.values['p(99)'].toFixed(1) + ' ms');
  sortida += linia('maxim', m.http_req_duration.values.max.toFixed(1) + ' ms');
  sortida += '\n  --- ERRORS ---\n';
  sortida += linia('Taxa de fallada HTTP', (m.http_req_failed.values.rate * 100).toFixed(3) + ' %');

  return {
    'stdout': sortida,
    'resultats/pont-maig.json': JSON.stringify(data, null, 2),
  };
}

export const options = {
  vus: 3,
  duration: '2m',
  thresholds: {
    'http_req_failed': ['rate<0.01'],
    'http_req_duration': ['p(95)<500'],
  },
};

export const options = {
  scenarios: {
    carrega_normal: {
      executor: 'constant-arrival-rate',
      rate: 120,               // 120 peticions per segon, el transit habitual
      timeUnit: '1s',
      duration: '20m',
      preAllocatedVUs: 100,
      maxVUs: 500,
    },
  },
  thresholds: {
    'http_req_duration': ['p(95)<300'],
    'http_req_failed': ['rate<0.001'],
  },
};

export const options = {
  scenarios: {
    estres: {
      executor: 'ramping-arrival-rate',
      startRate: 50,
      timeUnit: '1s',
      preAllocatedVUs: 500,
      maxVUs: 5000,
      stages: [
        { duration: '3m', target: 100  },
        { duration: '3m', target: 200  },
        { duration: '3m', target: 400  },
        { duration: '3m', target: 600  },
        { duration: '3m', target: 800  },
        { duration: '3m', target: 1200 },
        { duration: '5m', target: 0    },   // Recuperacio: es recupera sol?
      ],
    },
  },
  // SENSE thresholds: volem que arribi fins al final encara que falli.
};

export const options = {
  scenarios: {
    punta: {
      executor: 'ramping-arrival-rate',
      startRate: 20,
      timeUnit: '1s',
      preAllocatedVUs: 100,
      maxVUs: 3000,
      stages: [
        { duration: '2m',  target: 20  },   // Calma
        { duration: '30s', target: 800 },   // PUNTA BRUTAL
        { duration: '3m',  target: 800 },   // Sostingut
        { duration: '2m',  target: 20  },   // Tornada a la calma
      ],
    },
  },
};

export const options = {
  scenarios: {
    resistencia: {
      executor: 'constant-arrival-rate',
      rate: 100,
      timeUnit: '1s',
      duration: '8h',            // VUIT HORES
      preAllocatedVUs: 100,
      maxVUs: 300,
    },
  },
};

# k8s/proves/job-carrega-pont-maig.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: script-carrega
  namespace: rutas-norte-pre
data:
  pont-maig.js: |
    // (el contingut de l'script de l'apartat 2)
---
apiVersion: batch/v1
kind: Job
metadata:
  name: carrega-pont-maig
  namespace: rutas-norte-pre
  labels:
    app: prova-carrega
    app.kubernetes.io/part-of: rutas-norte
spec:
  backoffLimit: 0        # Si falla, NO reintentar: falsejaria els resultats
  ttlSecondsAfterFinished: 86400
  template:
    metadata:
      labels:
        app: prova-carrega
    spec:
      restartPolicy: Never

      # El generador de carrega NO ha de competir per recursos amb el que mesura.
      # L'enviem a un node dedicat amb taint i toleration (06-05).
      tolerations:
        - key: rol
          operator: Equal
          value: proves
          effect: NoSchedule
      nodeSelector:
        rol: proves

      containers:
        - name: k6
          image: grafana/k6:0.52.0
          command: ["k6", "run"]
          args:
            - "--out"
            - "experimental-prometheus-rw"     # Envia metriques a Prometheus
            - "--tag"
            - "prova=pont-maig"
            - "/scripts/pont-maig.js"
          env:
            - name: URL_BASE
              value: "http://api-reserves.rutas-norte-pre.svc.cluster.local"
            - name: K6_PROMETHEUS_RW_SERVER_URL
              value: "http://prometheus-operated.monitoratge.svc.cluster.local:9090/api/v1/write"
            - name: K6_PROMETHEUS_RW_TREND_STATS
              value: "p(50),p(95),p(99),max"
          resources:
            # GENEROS A PROPOSIT. Si k6 es queda sense CPU, no genera la carrega
            # demanada i la prova MENTEIX: mesuraras un sistema que aguanta be
            # perque mai va rebre la carrega que et pensaves.
            requests:
              cpu: "2"
              memory: 2Gi
            limits:
              cpu: "4"
              memory: 4Gi
          volumeMounts:
            - name: scripts
              mountPath: /scripts
      volumes:
        - name: scripts
          configMap:
            name: script-carrega

kubectl apply -f k8s/proves/job-carrega-pont-maig.yaml
kubectl logs -f job/carrega-pont-maig -n rutas-norte-pre

apiVersion: k6.io/v1alpha1
kind: TestRun
metadata:
  name: carrega-pont-maig
  namespace: rutas-norte-pre
spec:
  parallelism: 4          # Quatre pods generant carrega en paral·lel
  script:
    configMap:
      name: script-carrega
      file: pont-maig.js
  runner:
    resources:
      requests: {cpu: "2", memory: 2Gi}
      limits: {cpu: "2", memory: 2Gi}

     ✓ la cerca retorna 200
     ✓ la cerca retorna rutes
     ✗ la reserva retorna 201
      ↳  97% — ✓ 8214 / ✗ 254

     checks.........................: 98.42% ✓ 47892     ✗ 768
     data_received..................: 1.2 GB  1.8 MB/s
     data_sent......................: 89 MB   134 kB/s
     duracio_cerca_rutes............: avg=98.4ms  min=12ms  med=71ms   max=4.2s   p(95)=241ms  p(99)=892ms
     duracio_confirmar_reserva......: avg=421ms   min=89ms  med=302ms  max=8.9s   p(95)=1.4s   p(99)=4.1s
     errors_reserva.................: 2.96%  ✓ 254       ✗ 8214
     http_req_blocked...............: avg=1.2ms   min=0s    med=2µs    max=1.1s   p(95)=4µs
     http_req_connecting............: avg=0.9ms   min=0s    med=0s     max=892ms  p(95)=0s
   ✗ http_req_duration..............: avg=142ms   min=8ms   med=68ms   max=8.9s   p(95)=487ms  p(99)=2.1s
       { expected_response:true }...: avg=131ms   min=8ms   med=66ms   max=6.2s   p(95)=443ms
   ✗ http_req_failed................: 1.34%  ✓ 892       ✗ 65432
     http_reqs......................: 66324  99.4/s
     iteration_duration.............: avg=6.8s    min=3.1s  med=6.4s   max=22s    p(95)=12.4s
     iterations.....................: 14204  21.3/s
     vus............................: 187    min=20      max=1240
     vus_max........................: 3000   min=3000    max=3000

     reserves_confirmades...........: 8214   12.3/s

ERRO[0942] thresholds on metrics 'http_req_duration, http_req_failed, errors_reserva' have been crossed

http_req_duration: avg=142ms   med=68ms   p(95)=487ms   p(99)=2.1s   max=8.9s

Temps d'espera ≈ TempsServei × (utilitzacio / (1 - utilitzacio))

Utilitzacio 50 %:  espera = 1,0 x temps de servei
Utilitzacio 80 %:  espera = 4,0 x temps de servei
Utilitzacio 90 %:  espera = 9,0 x temps de servei
Utilitzacio 95 %:  espera = 19,0 x temps de servei
Utilitzacio 99 %:  espera = 99,0 x temps de servei

http_req_failed: 1.34%  ✓ 892  ✗ 65432
errors_reserva:  2.96%  ✓ 254  ✗ 8214

Configuracio "raonable" d'api-reserves (Node.js amb pg-pool):
  pool.max = 20 connexions

Situacio normal: 4 repliques.
  Connexions totals: 4 x 20 = 80.
  postgres-reserves: max_connections = 200.
  80 < 200. Tot be.

PONT DE MAIG: l'HPA escala a 30 repliques.
  Connexions totals: 30 x 20 = 600.
  max_connections = 200.

  400 connexions REBUTJADES.

1. Les repliques 11 a 30 no aconsegueixen connexio.
2. Les seves peticions fallen amb "too many connections" o esperen fins al timeout.
3. api-reserves retorna 500. La CPU PUJA (gestio d'errors, reintents).
4. L'HPA veu mes CPU i vol escalar MES. maxReplicas ho talla en 30.
5. Les 10 repliques que SI tenen connexio reben tot el transit.
6. PostgreSQL, amb 200 connexions actives, dedica mes temps a canviar de
   context entre processos que a executar consultes.
7. Les consultes s'alenteixen. Les connexions es retenen mes temps.
8. Col·lapse total.

repliques_maximes x pool_per_replica  <=  max_connections x 0,8

maxReplicas d'api-reserves: 30
max_connections de postgres-reserves: 200
Reserva del 20 %: 200 x 0,8 = 160

pool_per_replica <= 160 / 30 = 5,33  ->  5 connexions per replica

Concurrencia = Taxa d'arribada x Temps de servei

Amb 5 connexions i una consulta mitjana de 8 ms:
  Consultes per segon = 5 / 0,008 = 625 consultes/s per replica

Si cada peticio HTTP fa 2 consultes de mitjana:
  Peticions per segon = 625 / 2 = 312 rps per replica

# ConfigMap d'api-reserves
apiVersion: v1
kind: ConfigMap
metadata:
  name: api-reserves-config
  namespace: rutas-norte-pro
data:
  # POOL DE CONNEXIONS A POSTGRESQL
  #
  # Calcul: maxReplicas (30) x POOL_MAX <= max_connections (200) x 0,8 = 160
  #         POOL_MAX <= 160 / 30 = 5,33  ->  5
  #
  # Verificacio de capacitat (llei de Little):
  #   5 connexions / 8 ms per consulta = 625 consultes/s per replica
  #   Amb 2 consultes per peticio: 312 rps per replica.
  #   Punt d'inflexio mesurat: 112 rps per replica.
  #   El pool NO es el limitant. En sobra amb 5.
  #
  # NO PUJAR sense recalcular. Amb 30 repliques, cada connexio extra per replica
  # son 30 connexions mes contra un limit de 200.
  PG_POOL_MAX: "5"
  PG_POOL_MIN: "2"

  # Timeout d'espera per una connexio lliure. 3 segons: preferim fallar
  # rapid (l'usuari reintenta) a acumular peticions esperant.
  PG_POOL_ACQUIRE_TIMEOUT_MS: "3000"

  # Tancar connexions ocioses als 30 s: allibera recursos a PostgreSQL
  # quan l'HPA baixa repliques.
  PG_POOL_IDLE_TIMEOUT_MS: "30000"

  # Reciclar connexions cada 30 minuts: evita connexions zombis i fuites
  # de memoria del costat del servidor.
  PG_POOL_MAX_LIFETIME_MS: "1800000"

# k8s/base/deployment-pgbouncer.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: pgbouncer
  namespace: rutas-norte-pro
  labels:
    app: pgbouncer
    app.kubernetes.io/part-of: rutas-norte
spec:
  replicas: 3
  selector:
    matchLabels:
      app: pgbouncer
  template:
    metadata:
      labels:
        app: pgbouncer
    spec:
      topologySpreadConstraints:
        - maxSkew: 1
          topologyKey: topology.kubernetes.io/zone
          whenUnsatisfiable: DoNotSchedule
          labelSelector:
            matchLabels:
              app: pgbouncer
      containers:
        - name: pgbouncer
          image: bitnami/pgbouncer:1.22.1
          env:
            - name: PGBOUNCER_POOL_MODE
              # TRANSACTION: la connexio al servidor s'assigna nomes durant
              # una transaccio. Es el que permet la multiplexacio massiva.
              # ADVERTENCIA: incompatible amb sentencies preparades de sessio,
              # cursors amb nom i LISTEN/NOTIFY. L'aplicacio ha d'estar
              # escrita tenint-ho en compte.
              value: "transaction"
            - name: PGBOUNCER_MAX_CLIENT_CONN
              # 1000 connexions de CLIENT. Amb 30 repliques x 20 = 600. En sobra.
              value: "1000"
            - name: PGBOUNCER_DEFAULT_POOL_SIZE
              # Nomes 25 connexions al SERVIDOR per base de dades i usuari.
              # Amb 3 repliques de pgbouncer: 75 connexions totals a PostgreSQL,
              # molt per sota de les 200. I estables: no depenen de l'HPA.
              value: "25"
            - name: PGBOUNCER_RESERVE_POOL_SIZE
              value: "5"
          resources:
            requests: {cpu: 100m, memory: 128Mi}
            limits: {cpu: 500m, memory: 256Mi}

// MALAMENT: una consulta per a les rutes, i una MES per cada ruta. N+1.
const rutes = await db.query(
  'SELECT id, origen, desti, hora_sortida FROM rutes WHERE origen=$1 AND desti=$2',
  [origen, desti]
);

for (const ruta of rutes) {
  // Si hi ha 30 rutes, aixo son 30 consultes ADDICIONALS.
  ruta.placesLliures = await db.query(
    'SELECT COUNT(*) FROM places WHERE ruta_id=$1 AND estat=$2',
    [ruta.id, 'lliure']
  );
}
// TOTAL: 31 consultes per respondre UNA peticio.

// BE: UNA sola consulta amb agregacio.
const rutes = await db.query(`
  SELECT
    r.id, r.origen, r.desti, r.hora_sortida,
    COUNT(p.id) FILTER (WHERE p.estat = 'lliure') AS places_lliures
  FROM rutes r
  LEFT JOIN places p ON p.ruta_id = r.id
  WHERE r.origen = $1 AND r.desti = $2 AND r.data = $3
  GROUP BY r.id, r.origen, r.desti, r.hora_sortida
  ORDER BY r.hora_sortida
`, [origen, desti, data]);
// TOTAL: 1 consulta.

-- Diagnostic: com executa PostgreSQL aquesta consulta?
EXPLAIN (ANALYZE, BUFFERS)
SELECT * FROM rutes WHERE origen = 'BIL' AND desti = 'MAD' AND data = '2026-05-01';

Seq Scan on rutes  (cost=0.00..18432.00 rows=12 width=84) (actual time=0.031..89.412 rows=8 loops=1)
  Filter: ((origen = 'BIL') AND (desti = 'MAD') AND (data = '2026-05-01'))
  Rows Removed by Filter: 847992
  Buffers: shared hit=2841 read=5591
Planning Time: 0.184 ms
Execution Time: 89.487 ms

-- L'index compost que resol la consulta
CREATE INDEX CONCURRENTLY idx_rutes_cerca
  ON rutes (origen, desti, data)
  INCLUDE (hora_sortida, preu_base);

Index Scan using idx_rutes_cerca on rutes  (cost=0.42..8.61 rows=12 width=84)
                                           (actual time=0.024..0.041 rows=8 loops=1)
  Index Cond: ((origen = 'BIL') AND (desti = 'MAD') AND (data = '2026-05-01'))
  Buffers: shared hit=5
Planning Time: 0.211 ms
Execution Time: 0.068 ms

-- Requereix l'extensio pg_stat_statements
SELECT
  substring(query, 1, 80) AS consulta,
  calls,
  round(mean_exec_time::numeric, 2) AS mitjana_ms,
  round(total_exec_time::numeric / 1000, 1) AS total_s,
  rows / GREATEST(calls, 1) AS files_per_crida
FROM pg_stat_statements
ORDER BY total_exec_time DESC
LIMIT 15;

kubectl exec -n rutas-norte-pro redis-cache-0 -- redis-cli INFO stats | grep keyspace

keyspace_hits:1284729
keyspace_misses:8471203

Taxa d'encerts = 1.284.729 / (1.284.729 + 8.471.203) = 13,2 %

// MALAMENT: la clau inclou la marca de temps exacta de la peticio.
// CADA peticio genera una clau diferent. Taxa d'encerts ~0 %.
const clau = `places:${rutaId}:${Date.now()}`;

// MALAMENT: inclou l'identificador de l'usuari, que no afecta el resultat.
const clau = `rutes:${origen}:${desti}:${data}:${usuariId}`;

// BE: nomes els parametres que determinen el resultat.
const clau = `rutes:${origen}:${desti}:${data}`;

Sense cache: 500 consultes/s a PostgreSQL.
Amb TTL de 10 s: 1 consulta cada 10 s = 0,1 consultes/s a PostgreSQL.

Reduccio: 5.000 vegades.
Cost: les dades poden estar fins a 10 segons desactualitzades.

# ConfigMap de redis-cache
maxmemory 1500mb
maxmemory-policy allkeys-lru
# allkeys-lru: en omplir-se, expulsa les claus menys usades recentment.
# SENSE aixo, Redis creix fins a l'OOMKilled (ho vam veure a 09-02).

# ConfigMap de botiga-web: /etc/nginx/conf.d/rutas-norte.conf

# --- COMPRESSIO ---
gzip on;
gzip_vary on;
gzip_min_length 1024;          # No comprimir el petit: el cost de CPU no compensa
gzip_comp_level 5;             # 5 de 9: bon equilibri. El 9 gasta molta CPU
                               # per un 2-3 % mes de compressio
gzip_types
    text/plain text/css text/javascript
    application/javascript application/json
    application/xml image/svg+xml;

# Brotli comprimeix un 15-20 % millor que gzip per a text.
# PRECOMPRIMIT al build: cost de CPU ZERO en temps d'execucio.
brotli_static on;
gzip_static on;

# --- CACHE D'ACTIUS ---
# Els fitxers amb hash al nom (app.4f8a2c.js) son IMMUTABLES:
# si canvia el contingut, canvia el nom. Es poden cachejar un any.
location ~* \.(js|css|woff2|png|jpg|svg)$ {
    expires 1y;
    add_header Cache-Control "public, immutable";
    access_log off;            # No registrar actius: redueix E/S un 80 %
}

# L'HTML NO es cacheja: es el que apunta als fitxers amb hash.
location = /index.html {
    expires -1;
    add_header Cache-Control "no-cache, must-revalidate";
}

# --- CONNEXIONS PERSISTENTS CAP A api-reserves ---
upstream api_reserves {
    server api-reserves.rutas-norte-pro.svc.cluster.local:8080;
    # 64 connexions persistents reutilitzades. Sense aixo, nginx obre i tanca
    # una connexio TCP per peticio: 3 paquets de handshake mes el tancament.
    keepalive 64;
    keepalive_requests 1000;
    keepalive_timeout 60s;
}

location /api/ {
    proxy_pass http://api_reserves/;
    # OBLIGATORI perque keepalive funcioni: HTTP/1.1 i sense capcalera
    # Connection heretada del client.
    proxy_http_version 1.1;
    proxy_set_header Connection "";
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
}

Cost d'una connexio TCP nova (dins del cluster):
  SYN -> SYN/ACK -> ACK:  ~0,4 ms (3 paquets)
  Tancament (FIN/ACK x2): ~0,2 ms
  Total: ~0,6 ms de latencia afegida per peticio

Amb 500 peticions/s: 300 ms/s de latencia acumulada.

I pitjor: els ports efimers del costat de nginx s'esgoten.
El rang tipic son ~28.000 ports. Amb TIME_WAIT de 60 s:
  28.000 / 60 = 466 connexions noves per segon COM A MAXIM.
Per sobre d'aixo: errors de "cannot assign requested address".

// api-reserves: agent HTTP amb connexions persistents
const http = require('http');
const agent = new http.Agent({
  keepAlive: true,
  keepAliveMsecs: 30000,
  maxSockets: 50,
  maxFreeSockets: 10,
  timeout: 5000,
});

cfs_period_us = 100.000 (100 ms)
cfs_quota_us  = 100.000 (100 ms de CPU per cada 100 ms de rellotge)

cfs_period_us = 100.000 (100 ms)
cfs_quota_us  =  50.000 (50 ms de CPU per cada 100 ms de rellotge)

api-reserves amb limits.cpu: 1  ->  quota de 100 ms per periode de 100 ms.

Node.js amb 4 fils actius (el bucle d'esdeveniments + 3 del pool de libuv
per a criptografia, compressio i DNS):

Periode de 100 ms:
  t=0 ms:   els 4 fils comencen a treballar
  t=25 ms:  4 fils x 25 ms = 100 ms de CPU consumits. QUOTA ESGOTADA.
  t=25 ms:  el kernel ATURA tots els fils.
  t=100 ms: nou periode. Es reprenen.

RESULTAT: el contenidor nomes treballa 25 ms de cada 100.
          Esta aturat el 75 % DEL TEMPS DE RELLOTGE.

I tanmateix, kubectl top mostra:
  CPU: 1000m (100 % del limit)

Va consumir exactament la seva quota. Sembla "al limit" i no "estrangulat".
Pero qualsevol peticio que arribi a t=30 ms ESPERA 70 ms sense fer res.

t=12,5 ms: quota esgotada.
El contenidor treballa 12,5 ms de cada 100: el 12,5 % del temps.
Una peticio que arribi a t=20 ms espera 80 ms.

I kubectl top mostraria 500m: "al 100 % del seu limit".

# Percentatge de periodes en els quals el contenidor va ser estrangulat
rate(container_cpu_cfs_throttled_periods_total{
  namespace="rutas-norte-pro", container="api"
}[5m])
/
rate(container_cpu_cfs_periods_total{
  namespace="rutas-norte-pro", container="api"
}[5m])
* 100

# Segons d'estrangulament per segon: quant temps REAL es perd
rate(container_cpu_cfs_throttled_seconds_total{
  namespace="rutas-norte-pro", container="api"
}[5m])

api-reserves, limits.cpu: 1, 4 repliques, 340 rps:
  Periodes estrangulats: 18,4 %
  Temps estrangulat: 0,31 s/s
  Latencia p95: 287 ms
  Latencia p99: 891 ms

resources:
  requests:
    cpu: 412m         # Reserva garantida
    memory: 800Mi
  limits:
    # SENSE limits.cpu
    memory: 1600Mi    # El limit de memoria SI que es mante

# api-reserves: SENSE limit de CPU
resources:
  requests:
    cpu: 412m          # Reserva garantida. Pes en el repartiment.
    memory: 800Mi
  limits:
    # SENSE limits.cpu DELIBERADAMENT.
    #
    # Motiu: amb limits.cpu: 1 mesuravem un 18,4 % de periodes estrangulats
    # i un p99 de 891 ms. Node.js fa servir diversos fils (bucle d'esdeveniments
    # + pool de libuv) i esgota la quota de 100 ms en ~25 ms de rellotge.
    #
    # Sense limit:
    #   - Estrangulament: 0 %
    #   - p99: 891 ms -> 340 ms
    #   - Arrencada: 25 s -> 9 s (rellevant per a l'autoescalat, 09-01)
    #
    # Risc assumit: un pod defectuos pot consumir la CPU sobrant del
    # node. Mitigacions:
    #   - El requests garanteix el minim de tots els altres pods.
    #   - LimitRange del namespace imposa un sostre de 4 nuclis per contenidor.
    #   - Alerta si un pod supera 3x el seu requests durant 10 minuts.
    #
    # El LIMIT DE MEMORIA SI QUE ES MANTE: la memoria NO es compressible i
    # un pod sense limit de memoria pot tombar el node sencer.
    memory: 1600Mi

# Un pod que consumeix mes del triple del seu requests de forma sostinguda
(
  rate(container_cpu_usage_seconds_total{namespace="rutas-norte-pro"}[10m])
  /
  on(pod, container) kube_pod_container_resource_requests{resource="cpu"}
) > 3

Node de 16 GiB. Contenidor amb limits.memory: 1Gi.

Node.js (segons versio i configuracio) pot decidir un heap maxim
basant-se en els 16 GiB de l'amfitrio, no en l'1 GiB del contenidor.

Resultat: el recol·lector d'escombraries no s'activa amb urgencia perque creu
que te memoria de sobres. El heap creix fins a fregar el GiB del contenidor.

El kernel: OOMKilled.

I el pitjor: el proces mor SENSE avis ni traca. Nomes apareix "OOMKilled"
a l'estat del pod. Node.js ni se n'assabenta.

env:
  # --max-old-space-size fixa la mida maxima del heap d'objectes antics
  # en MEGABYTES.
  #
  # Calcul per a un limits.memory de 1600Mi:
  #   Heap de JavaScript:  1024 MB   (--max-old-space-size=1024)
  #   Buffers i ArrayBuffer:  ~200 MB (fora del heap)
  #   Codi natiu i biblioteques: ~150 MB
  #   Pila i estructures internes:  ~80 MB
  #   Marge de seguretat:          ~146 MB
  #   -------------------------------------
  #   TOTAL:                       1600 MB
  #
  # REGLA PRACTICA: heap = 65-70 % del limits.memory. La resta NO es
  # malbaratament: es memoria que Node.js necessita fora del heap.
  - name: NODE_OPTIONS
    value: "--max-old-space-size=1024"

# Us de memoria davant del limit
container_memory_working_set_bytes{namespace="rutas-norte-pro", container="api"}
/
on(pod, container) kube_pod_container_resource_limits{resource="memory"}

# OOMKilled recents: el senyal inequivoc
increase(kube_pod_container_status_restarts_total{namespace="rutas-norte-pro"}[1h]) > 0
and on(pod, container)
kube_pod_container_status_last_terminated_reason{reason="OOMKilled"} == 1

Pressupost: 12 nuclis i 24 GiB per a api-reserves.

Opcio A: 30 pods de 400m i 800Mi
Opcio B: 12 pods d'1 nucli i 2 GiB
Opcio C:  6 pods de 2 nuclis i 4 GiB

Pod d'api-reserves amb 4 nuclis:
  - El bucle d'esdeveniments fa servir 1 nucli com a maxim.
  - El pool de libuv (4 fils per defecte) fa servir alguna cosa mes per a E/S de fitxers,
    DNS, criptografia i compressio.
  - A la practica, un proces de Node.js aprofita ~1,3 nuclis.

Els altres 2,7 nuclis ESTAN MALGASTATS.

# api-reserves: 12 pods d'1 nucli (opcio B), no 30 de 400m ni 6 de 2 nuclis.
#
# Contra l'opcio A (30 pods de 400m):
#   - 30 pools de connexions contra PostgreSQL (veure apartat 6).
#   - 30 sidecars exportadors: 30 x 6m = 180m nomes en observabilitat.
#   - 400m es poc per a l'ARRENCADA de Node.js, que consumeix molta CPU
#     compilant: l'arrencada passaria de 9 s a mes de 30 s.
#
# Contra l'opcio C (6 pods de 2 nuclis):
#   - Node.js no aprofita 2 nuclis amb un sol proces.
#   - Perdre 1 de 6 repliques es perdre el 16,7 % de la capacitat.
#   - Granularitat d'escalat massa gruixuda.
#
# 1 nucli es el punt dolc: suficient per al bucle d'esdeveniments i el pool
# de libuv, amb marge per a l'arrencada, i granularitat fina per a l'HPA.
resources:
  requests:
    cpu: 412m           # Del VPA (09-02): consum real en regim permanent
    memory: 800Mi
  limits:
    memory: 1600Mi      # Sense limits.cpu (apartat 10)

L'HPA detecta la sobrecarrega i demana repliques noves.
Temps fins que una replica nova aten transit:

  Decisio de l'HPA:                       0-15 s (cicle de 15 s)
  Planificacio:                             1 s
  Descarrega de la imatge:                0-60 s (0 si esta cachejada)
  Arrencada del contenidor:              5-30 s
  Sonda de readiness OK:                 3-10 s
  ----------------------------------------------
  TOTAL:                                 9-116 s

# --- Etapa de construccio ---
FROM node:20.15-bookworm AS constructor
WORKDIR /app
COPY package*.json ./
# npm ci amb --omit=dev: nomes dependencies de produccio
RUN npm ci --omit=dev
COPY . .
RUN npm run build

# --- Etapa final: NOMES el necessari per executar ---
FROM node:20.15-alpine
WORKDIR /app
# Usuari sense privilegis (08-02)
RUN addgroup -g 10001 rutasnorte && adduser -u 10001 -G rutasnorte -D rutasnorte
COPY --from=constructor --chown=10001:10001 /app/node_modules ./node_modules
COPY --from=constructor --chown=10001:10001 /app/dist ./dist
COPY --from=constructor --chown=10001:10001 /app/package.json ./
USER 10001
EXPOSE 8080
CMD ["node", "dist/servidor.js"]

# k8s/entorns/pro/daemonset-precarrega-imatges.yaml
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: precarrega-imatges
  namespace: rutas-norte-pro
  labels:
    app: precarrega-imatges
    app.kubernetes.io/part-of: rutas-norte
spec:
  selector:
    matchLabels:
      app: precarrega-imatges
  template:
    metadata:
      labels:
        app: precarrega-imatges
    spec:
      # Prioritat baixa: si cal el forat, que se'n vagi.
      priorityClassName: farciment-capacitat
      # Els initContainers DESCARREGUEN les imatges al node i acaben.
      # A partir d'aqui queden a la cache local de containerd.
      initContainers:
        - name: precarregar-api
          image: registry.rutasnorte.example/api-reserves:1.14.2
          command: ["/bin/true"]
        - name: precarregar-web
          image: registry.rutasnorte.example/botiga-web:3.2.0
          command: ["/bin/true"]
        - name: precarregar-worker
          image: registry.rutasnorte.example/worker-notificacions:2.3.0
          command: ["/bin/true"]
      containers:
        - name: pausa
          image: registry.k8s.io/pause:3.9
          resources:
            requests: {cpu: 5m, memory: 8Mi}
            limits: {cpu: 10m, memory: 16Mi}

# MALAMENT: el pod triga 20 s de mes a rebre transit sense cap rao.
readinessProbe:
  httpGet: {path: /preparat, port: 8080}
  initialDelaySeconds: 30       # <- Espera 30 s fins i tot si esta llest en 5
  periodSeconds: 10             # <- Comprova cada 10 s: perd fins a 10 s mes
  failureThreshold: 3

# BE: startupProbe per a l'arrencada, readinessProbe agressiva despres.
startupProbe:
  httpGet: {path: /salut, port: 8080}
  # Comprova cada segon des del segon 0. Tan bon punt arrenqui, llest.
  periodSeconds: 1
  # 40 intents x 1 s = 40 segons de marge maxim per a l'arrencada.
  # Si triga mes, alguna cosa va malament i ho volem saber.
  failureThreshold: 40

readinessProbe:
  httpGet: {path: /preparat, port: 8080}
  # SENSE initialDelaySeconds: la startupProbe ja cobreix l'arrencada.
  periodSeconds: 2              # Comprovacio frequent: reacciona rapid
  timeoutSeconds: 1
  failureThreshold: 2
  successThreshold: 1

livenessProbe:
  httpGet: {path: /salut, port: 8080}
  periodSeconds: 10
  timeoutSeconds: 3
  # failureThreshold alt: NO matar el pod per un pic de latencia temporal.
  # Una livenessProbe agressiva sota carrega alta produeix reinicis en cascada:
  # el pod va lent -> falla la sonda -> es reinicia -> menys capacitat ->
  # els altres van mes lents -> es reinicien tambe. Espiral de mort.
  failureThreshold: 6

ABANS:
  Descarrega d'imatge (1,1 GB, sense cachejar):    48 s
  Arrencada de Node.js (amb limits.cpu: 1):        25 s
  initialDelaySeconds de la readiness:             30 s
  Cicles de sonda fins a passar:                   10 s
  ----------------------------------------------------
  TOTAL:                                          113 s

DESPRES:
  Descarrega (94 MB, precarregada per DaemonSet):   0 s
  Arrencada de Node.js (sense limits.cpu):          9 s
  startupProbe (comprova cada segon):               1 s
  readinessProbe (periode de 2 s):                  2 s
  ----------------------------------------------------
  TOTAL:                                           12 s

nameserver 10.96.0.10
search rutas-norte-pro.svc.cluster.local svc.cluster.local cluster.local
options ndots:5

1. api.correus-externs.example.rutas-norte-pro.svc.cluster.local  -> NXDOMAIN
2. api.correus-externs.example.svc.cluster.local                  -> NXDOMAIN
3. api.correus-externs.example.cluster.local                      -> NXDOMAIN
4. api.correus-externs.example                                    -> OK

QUATRE consultes DNS per resoldre un nom.
I com que el resolutor de glibc consulta A i AAAA: VUIT consultes en total.

300 resolucions/s x 8 consultes = 2.400 consultes DNS/s a CoreDNS.

Si cada resolucio afegeix 3 ms de latencia (4 anades i tornades fallides):
  300 x 3 ms = 900 ms/s de latencia acumulada malgastada.

I CoreDNS amb 2.400 consultes/s de les quals el 75 % son NXDOMAIN inutils.

// MALAMENT: 4 consultes pel ndots:5
const servidor = 'smtp.correus-externs.example';

// BE: el punt final marca el nom com a ABSOLUT.
// El resolutor NO prova els sufixos de search. UNA sola consulta.
const servidor = 'smtp.correus-externs.example.';

spec:
  dnsConfig:
    options:
      - name: ndots
        # Amb ndots: 2, qualsevol nom amb 2 o mes punts es prova
        # primer com a absolut. Els noms interns com
        # "postgres-reserves.rutas-norte-pro" (1 punt) continuen funcionant
        # amb els sufixos de search.
        value: "2"
      # Fallar rapid si el DNS no respon.
      - name: timeout
        value: "1"
      - name: attempts
        value: "2"

# ConfigMap de CoreDNS (kube-system/coredns)
apiVersion: v1
kind: ConfigMap
metadata:
  name: coredns
  namespace: kube-system
data:
  Corefile: |
    .:53 {
        errors
        health { lameduck 5s }
        ready

        kubernetes cluster.local in-addr.arpa ip6.arpa {
            pods insecure
            fallthrough in-addr.arpa ip6.arpa
            ttl 30
        }

        prometheus :9153

        forward . /etc/resolv.conf {
            max_concurrent 1000
            # Politica de repartiment entre servidors DNS externs.
            policy sequential
        }

        # CACHE: l'optimitzacio mes important de CoreDNS.
        #   3600 s (1 h) per a respostes positives del cluster
        #     30 s per a respostes negatives (NXDOMAIN)
        # El TTL curt per a negatives es DELIBERAT: quan es crea un
        # Service nou, no volem que els pods continuin rebent NXDOMAIN
        # durant una hora.
        cache 3600 {
            success 9984 3600
            denial 9984 30
        }

        loop
        reload
        loadbalance
    }

Regla practica: 1 replica de CoreDNS per cada 8-10 nodes, amb un minim de 2.

Cluster de Rutas Norte: 9-12 nodes al pic.
Repliques: 3 (una per zona, veure 09-05).

Si les metriques mostren latencia de DNS alta:
  histogram_quantile(0.99,
    sum(rate(coredns_dns_request_duration_seconds_bucket[5m])) by (le)
  ) > 0.05

...la solucio sol ser NodeLocal DNSCache, no mes repliques de CoreDNS.

# Activar IPVS a minikube
minikube start -p rutas-norte --extra-config=kube-proxy.mode=ipvs

# Verificar
kubectl logs -n kube-system -l k8s-app=kube-proxy | grep -i "proxy mode"

I0501 09:14:22.847 server_others.go: Using ipvs Proxier.

Sobrecarrega per node (kubelet, sistema, DaemonSets): ~0,95 nuclis i 2 GiB.

Nodes de 4 nuclis:  0,95 / 4  = 23,8 % de sobrecarrega
Nodes de 8 nuclis:  0,95 / 8  = 11,9 %
Nodes de 16 nuclis: 0,95 / 16 =  5,9 %

Amb 12 nuclis utils necessaris:
  Amb nodes de 4:  12 / 3,05 = 3,93 -> 4 nodes = 16 nuclis comprats (33 % d'exces)
  Amb nodes de 8:  12 / 7,05 = 1,70 -> 2 nodes = 16 nuclis comprats (33 % d'exces)
  Amb nodes de 16: 12 / 15,05 = 0,80 -> 1 node = 16 nuclis comprats (33 % d'exces)

Coincideixen per casualitat en aquest cas, pero el node de 16 ho te TOT en una
maquina: una fallada s'endu la plataforma sencera. I el CA no pot ajustar
amb granularitat menor a 16 nuclis.

StorageClass rutasnorte-rapida: SSD amb 3.000 IOPS aprovisionades.

Una escriptura de reserva a PostgreSQL implica:
  - Escriptura al WAL (write-ahead log):        1 IOPS
  - fsync del WAL (obligatori per a durabilitat): 1 IOPS
  - Actualitzacio de pagines de dades (diferida): ~0,3 IOPS amortitzades
  - Actualitzacio d'indexs:                      ~0,5 IOPS
  TOTAL: ~2,8 IOPS per reserva

Reserves per segon maximes per IOPS:
  3.000 / 2,8 = 1.071 reserves/s

I les lectures que NO son a shared_buffers ni a la cache del sistema
tambe consumeixen IOPS.

-- Taxa d'encerts de la cache de PostgreSQL
SELECT
  datname,
  blks_hit,
  blks_read,
  round(100.0 * blks_hit / GREATEST(blks_hit + blks_read, 1), 2) AS taxa_encerts
FROM pg_stat_database
WHERE datname = 'reserves';

 datname  | blks_hit  | blks_read | taxa_encerts
----------+-----------+-----------+--------------
 reserves | 892471203 |  18472941 |        97.97

# IOPS de lectura i escriptura del volum
rate(node_disk_reads_completed_total{device="nvme1n1"}[5m])
+ rate(node_disk_writes_completed_total{device="nvme1n1"}[5m])

# LA METRICA CLAU: temps que el disc esta ocupat.
# Si supera 0,8 (80 %), el disc esta saturat.
rate(node_disk_io_time_seconds_total{device="nvme1n1"}[5m])

# ConfigMap de postgres-reserves
data:
  postgresql.conf: |
    # --- MEMORIA (limits.memory del pod: 8 GiB) ---
    # shared_buffers: el 25 % de la memoria del contenidor. Es la
    # recomanacio classica i continua sent bona.
    shared_buffers = 2GB
    # effective_cache_size: estimacio de la cache TOTAL disponible
    # (shared_buffers + cache de pagines del sistema). NO reserva memoria:
    # nomes informa el planificador de consultes perque prefereixi indexs.
    effective_cache_size = 6GB
    # work_mem per operacio d'ordenacio o hash. COMPTE: es multiplica
    # pel nombre d'operacions concurrents. Amb 200 connexions i
    # 3 operacions cadascuna: 200 x 3 x 16MB = 9,6 GB. MES QUE EL LIMIT.
    # Per aixo 16MB i no mes.
    work_mem = 16MB
    maintenance_work_mem = 512MB

    # --- ESCRIPTURA A DISC ---
    # Repartir els fsync del checkpoint al llarg del 90 % de l'interval,
    # en lloc de fer-los de cop. Evita pics de latencia periodics.
    checkpoint_completion_target = 0.9
    # 15 minuts entre checkpoints: menys escriptures, mes temps de
    # recuperacio despres d'una caiguda. Compromis raonable.
    checkpoint_timeout = 15min
    max_wal_size = 4GB
    min_wal_size = 1GB

    # --- COSTOS D'ACCES (per al planificador) ---
    # random_page_cost = 1.1 en SSD (per defecte es 4.0, pensat per a discos
    # mecanics). Sense aquest ajust, el planificador EVITA els indexs creient
    # que l'acces aleatori es car, i fa escanejos sequencials inutils.
    # ES UN DELS AJUSTOS MES RENDIBLES EN SSD.
    random_page_cost = 1.1
    effective_io_concurrency = 200

    # --- CONNEXIONS ---
    max_connections = 200

    # --- ESTADISTIQUES ---
    shared_preload_libraries = 'pg_stat_statements'
    pg_stat_statements.max = 10000
    track_io_timing = on

# api-reserves (temps propi, sense dependencies)
histogram_quantile(0.95,
  sum(rate(api_reserves_duracio_propia_segons_bucket{
    namespace="rutas-norte-pro"
  }[5m])) by (le)
) * 1000 > 35

# postgres-reserves (temps de consulta vist des de l'API)
histogram_quantile(0.95,
  sum(rate(api_reserves_duracio_consulta_bd_segons_bucket{
    namespace="rutas-norte-pro"
  }[5m])) by (le)
) * 1000 > 45

# motor-preus (el major consumidor: alerta prioritaria)
histogram_quantile(0.95,
  sum(rate(motor_preus_duracio_segons_bucket{
    namespace="rutas-norte-pro"
  }[5m])) by (le)
) * 1000 > 80

# I l'objectiu global, que es el que li importa al negoci
histogram_quantile(0.95,
  sum(rate(ingress_nginx_request_duration_seconds_bucket{
    ingress="rutas-norte-public", path="/rutes"
  }[5m])) by (le)
) * 1000 > 300

Suma dels pressupostos dels components  <=  75 % de l'objectiu total.
El 25 % restant es marge.

Sense l'ajust de rendiment:
  Capacitat per replica: 85 rps.
  Per a 2.680 rps: 2.680 / 85 = 32 repliques.
  CPU necessaria: 32 x 412m = 13,2 nuclis.
  Nodes: 5 nodes de 8 nuclis nomes per a api-reserves.

Amb l'ajust:
  Capacitat per replica: 224 rps.
  Per a 2.680 rps: 2.680 / 224 = 12 repliques.
  CPU necessaria: 12 x 412m = 4,9 nuclis.
  Nodes: 2 nodes de 8 nuclis.

ESTALVI: 3 nodes al pic. I, mes important, el pic HI CAP en un cluster
que no requereix reconfigurar els grups de nodes ni renegociar quotes.

     ✓ la cerca retorna 200
     ✗ la reserva retorna 201
      ↳  91% — ✓ 6142 / ✗ 607

     checks.........................: 94.21% ✓ 38921  ✗ 2391
     duracio_cerca_rutes............: avg=142ms  min=18ms  med=94ms   max=8.1s   p(95)=387ms  p(99)=2.4s
     duracio_confirmar_reserva......: avg=891ms  min=112ms med=612ms  max=14.2s  p(95)=3.1s   p(99)=9.8s
     errors_reserva.................: 9.00%  ✓ 607  ✗ 6142
     http_req_duration..............: avg=284ms  min=12ms  med=118ms  max=14.2s  p(95)=982ms  p(99)=4.2s
     http_req_failed................: 3.42%  ✓ 1621  ✗ 45782
     http_reqs......................: 47403  158.0/s
     iterations.....................: 9847   32.8/s
     vus............................: 412    min=50   max=1800

CPU mitjana per replica d'api-reserves:     680m de 1000m limit (68 %)
Periodes de CPU estrangulats:               31,2 %
Memoria mitjana:                            620Mi de 1600Mi (39 %)
Connexions actives a PostgreSQL:            118 de 200
Taxa d'encerts de redis-cache:              22,4 %
Consultes a PostgreSQL per segon:           3.840
Latencia p95 de les consultes a PostgreSQL:  41 ms
IOPS del disc de postgres:                  2.847 de 3.000 aprovisionades
Temps d'E/S del disc (io_time):              0,91

http_req_duration p95: 982 ms   (objectiu: 300 ms)   -> 3,3 vegades pitjor
duracio_cerca_rutes p95: 387 ms                      -> 1,3 vegades pitjor
duracio_confirmar_reserva p95: 3.100 ms              -> 10,3 vegades pitjor

errors_reserva: 9,00 %  ->  9 de cada 100 reserves FALLEN.

IOPS del disc: 2.847 de 3.000 aprovisionades  ->  94,9 % de la capacitat
Temps d'E/S del disc (io_time): 0,91          ->  91 % del temps ocupat

Espera ≈ TempsServei x (0,91 / (1 - 0,91)) = 10,1 x TempsServei

Taxa d'encerts de redis-cache: 22,4 %
-> El 77,6 % de les consultes de disponibilitat van a PostgreSQL.

Consultes a PostgreSQL: 3.840/s amb 158 peticions/s
-> 24,3 consultes per peticio HTTP.

1. La cache de Redis no funciona (22,4 % d'encerts).
2. Hi ha un problema N+1: 24 consultes per peticio.
3. 3.840 consultes/s contra PostgreSQL.
4. La cache de PostgreSQL no dona l'abast: moltes van a disc.
5. El disc al 91 % d'ocupacio: cada operacio espera 10 vegades el seu temps.
6. Les consultes s'alenteixen (el p95 de 41 ms ja ho reflecteix).
7. Les connexions es retenen mes temps: 118 de 200 actives.
8. Les escriptures (reserves) pateixen mes que les lectures: 3,1 s de p95.
9. Els timeouts produeixen el 9 % d'errors a les reserves.

CPU: 680m de 1000m (68 %)              -> hi ha marge
Memoria: 620Mi de 1600Mi (39 %)        -> hi ha molt marge
Connexions: 118 de 200 (59 %)          -> hi ha marge

"CPU 680m de 1000m (68 %)" es la MITJANA sobre l'interval de mesurament.
"31,2 % de periodes estrangulats" compta periodes de 100 ms individuals.

Que passa realment dins de cada periode de 100 ms:

  Periode A (69 % dels casos): el pod fa servir 40 ms dels seus 100 ms de quota.
                                No s'estrangula.
  Periode B (31 % dels casos): arriba una rafega. Node.js fa servir diversos fils
                                (bucle d'esdeveniments + libuv per a la
                                serialitzacio JSON i la compressio).
                                4 fils x 25 ms = 100 ms. QUOTA ESGOTADA
                                en 25 ms de rellotge.
                                El pod esta ATURAT 75 ms.

Mitjana ponderada: 0,69 x 40 + 0,31 x 100 = 27,6 + 31 = 58,6...
Ajustant per la distribucio real de rafegues: ~68 %. Coincideix.

-- Abans: 1 consulta de rutes + 23 consultes de places i preus
-- Despres: 1 consulta amb agregacio
SELECT
  r.id, r.origen, r.desti, r.hora_sortida, r.preu_base,
  COUNT(p.id) FILTER (WHERE p.estat = 'lliure') AS places_lliures
FROM rutes r
LEFT JOIN places p ON p.ruta_id = r.id
WHERE r.origen = $1 AND r.desti = $2 AND r.data = $3
GROUP BY r.id, r.origen, r.desti, r.hora_sortida, r.preu_base
ORDER BY r.hora_sortida;

Consultes: 3.840/s -> 316/s (divisio per 12)
IOPS del disc: 2.847 -> ~240 (per sota del 10 % de la capacitat)
io_time: 0,91 -> ~0,12
p95 de les consultes: 41 ms -> ~6 ms

p95 global estimat: 982 ms -> ~250 ms
Errors de reserva: 9,0 % -> < 0,5 %

# Diagnostic primer
kubectl exec -n rutas-norte-pre redis-cache-0 -- redis-cli INFO stats
kubectl exec -n rutas-norte-pre redis-cache-0 -- redis-cli --scan --count 20

// Clau: nomes els parametres que determinen el resultat
const clau = `places:${rutaId}`;
const ttl = 10;   // 10 segons: absorbeix el 95 % de les lectures

resources:
  requests:
    cpu: 500m
    memory: 800Mi
  limits:
    # Sense limits.cpu: elimina el 31,2 % de periodes estrangulats
    memory: 1600Mi

Estrangulament: 31,2 % -> 0 %
p99: 4,2 s -> ~1,5 s (elimina les esperes de 75 ms)
p95: millora del 10-15 %

Amb 6 repliques: 3.840 consultes/s. Disc al 91 %.
Amb 12 repliques: 7.680 consultes/s. Disc al... no pot passar del 100 %.

Resultat: les consultes s'encuen. La latencia PUJA.
Les connexions s'esgoten (12 repliques x pool). Mes errors.
Cost: el doble. Rendiment: pitjor.

max_connections de postgres-reserves:              200
Reserva per a manteniment, copies i metriques:      40 (20 %)
Disponible per a aplicacions:                      160
Ja usades per api-reserves (via PgBouncer):         75
------------------------------------------------------
Disponible per a api-empreses:                      85

maxReplicas d'api-empreses: 20
Pool maxim per replica: 85 / 20 = 4,25  ->  4 connexions

Concurrencia = Taxa d'arribada x Temps de servei

Cada peticio fa 6 consultes de 14 ms = 84 ms de temps de base de dades.

Consultes per segon que sosté una replica amb 4 connexions:
  4 connexions / 0,014 s = 285,7 consultes/s

Peticions per segon per replica:
  285,7 / 6 consultes = 47,6 peticions/s

Amb 20 repliques: 20 x 47,6 = 952 peticions/s

Transit del pic: 180 peticions/s
Capacitat amb 20 repliques: 952 peticions/s

952 >> 180.  EL POOL BASTA AMB MOLTISSIM MARGE.

180 peticions/s / 47,6 per replica = 3,78  ->  4 repliques

20 repliques x 4 connexions = 80 connexions.
Disponibles per a api-empreses: 85.
80 < 85. HI CAP, amb 5 de marge.

Suma dels components (sense marge): 685 ms
685 / 900 = 76,1 %  <=  75 %... just al limit.

Acceptable, pero ajustat. Convé vigilar-ho.

MESURAT a rutas-norte-pre amb 4 repliques:
  p95 total:                640 ms
  Dels quals, PostgreSQL:   310 ms
  Resta (aplicacio, xarxa, motor-preus): 330 ms

PRESSUPOSTAT:
  PostgreSQL: 300 ms   ->  mesurat 310 ms. DESVIACIO: +10 ms (+3,3 %)
  Resta:      385 ms   ->  mesurat 330 ms. Per sota. BE.
  Total:      900 ms   ->  mesurat 640 ms. MARGE: 260 ms (28,9 %)

310 ms mesurats / 6 consultes = 51,7 ms per consulta.
Pressupost: 50 ms per consulta.

I l'enunciat diu que la durada mitjana de cada consulta es 14 ms.
310 ms mesurats / 6 = 51,7 ms de p95 per consulta, davant de 14 ms de mitjana.

RATIO p95/mitjana = 3,7. Es alt.

SELECT
  substring(query, 1, 60),
  calls,
  round(mean_exec_time::numeric, 2) AS mitjana,
  round(stddev_exec_time::numeric, 2) AS desviacio,
  round(max_exec_time::numeric, 2) AS maxim
FROM pg_stat_statements
WHERE query LIKE '%bitllets%'
ORDER BY total_exec_time DESC;

Capacitat mesurada per replica: 47,6 peticions/s (limitada pel pool).

Pero cal verificar quin es el limitant REAL:
  - Pel pool: 47,6 rps
  - Per CPU: cal mesurar-ho amb la prova d'estres

Prenem el mes restrictiu. Suposem que la prova d'estres dona un punt
d'inflexio en 42 rps per replica (la CPU limita abans que el pool).

Apliquem el marge del 30 % per cobrir el temps d'arrencada:
  42 x 0,7 = 29,4  ->  threshold: 29 rps per replica

Verificacio al pic:
  180 rps / 29 = 6,2  ->  7 repliques.
  7 repliques x 4 connexions = 28 connexions a PostgreSQL. Molt folgat.

# k8s/entorns/pro/scaledobject-api-empreses.yaml
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: api-empreses
  namespace: rutas-norte-pro
spec:
  scaleTargetRef:
    name: api-empreses

  # 3 repliques de terra: una per zona (09-05). Es una API B2B amb contracte
  # de servei; no pot tenir arrencades en fred.
  minReplicaCount: 3

  # 20 repliques de sostre.
  # VERIFICACIO DE CONNEXIONS: 20 x 4 = 80 <= 85 disponibles. Hi cap.
  # NO PUJAR sense recalcular el pool (veure ConfigMap).
  maxReplicaCount: 20

  fallback:
    failureThreshold: 3
    replicas: 7        # La capacitat del pic: numero segur conegut

  advanced:
    horizontalPodAutoscalerConfig:
      behavior:
        scaleUp:
          stabilizationWindowSeconds: 0
          policies:
            - type: Pods
              value: 4
              periodSeconds: 30
        scaleDown:
          stabilizationWindowSeconds: 600
          policies:
            - type: Percent
              value: 25
              periodSeconds: 120

  triggers:
    - type: prometheus
      metadata:
        serverAddress: http://prometheus-operated.monitoratge.svc.cluster.local:9090
        metricName: api_empreses_peticions_per_segon
        query: |
          sum(rate(api_empreses_peticions_total{namespace="rutas-norte-pro"}[2m]))
        # 29 peticions/s per replica.
        #
        # Calcul:
        #   Punt d'inflexio mesurat (prova d'estres): 42 rps per replica.
        #   Marge del 30 % per cobrir l'arrencada: 42 x 0,7 = 29,4 -> 29.
        #
        # Verificacio del pool (llei de Little):
        #   4 connexions / 14 ms = 285,7 consultes/s per replica
        #   285,7 / 6 consultes per peticio = 47,6 rps per replica
        #   El POOL suporta 47,6 rps; la CPU limita abans en 42.
        #   El pool NO es el limitant. Correcte.
        threshold: "29"
        activationThreshold: "2"
      authenticationRef:
        kind: ClusterTriggerAuthentication
        name: prometheus-lectura

apiVersion: v1
kind: ConfigMap
metadata:
  name: api-empreses-config
  namespace: rutas-norte-pro
data:
  # POOL DE CONNEXIONS: 4 per replica.
  #
  # Calcul:
  #   max_connections de postgres-reserves:        200
  #   Reserva per a manteniment i metriques (20 %): -40
  #   Usades per api-reserves (via PgBouncer):      -75
  #   Disponibles per a api-empreses:                85
  #   maxReplicas d'api-empreses:                    20
  #   Pool = 85 / 20 = 4,25  ->  4
  #
  # NO PUJAR el pool ni el maxReplicas sense refer aquest calcul.
  # Amb 20 repliques, cada connexio extra per replica son 20 connexions mes.
  PG_POOL_MAX: "4"
  PG_POOL_MIN: "1"
  PG_POOL_ACQUIRE_TIMEOUT_MS: "2000"

1. Hi ha una fuita de memoria a api-reserves. La memoria creix ~40Mi/dia.
   (620Mi -> 1.480Mi en 21 dies = 41Mi/dia)

2. En arribar a ~1.500Mi d'un limit de 1.600Mi, el pod es OOMKilled.

3. CADA REINICI PER OOMKilled BUIDA LA CACHE EN MEMORIA DEL PROCES.
   Si api-reserves mante una cache local (a mes de Redis), es perd.

4. I MES IMPORTANT: els reinicis trenquen el patro d'acces a Redis.
   Un pod acabat d'arrencar fa consultes "fredes": demana claus que no
   estan cachejades perque la feina de poblar la cache la feia el pod
   anterior amb les seves dades de sessio.

5. La taxa d'encerts de Redis cau del 94,7 % al 71,2 %.

6. El 28,8 % de fallades (davant del 5,3 % anterior) es tradueix en
   5,4 vegades mes consultes a PostgreSQL: 340 -> 1.890/s.

7. Mes consultes -> mes latencia per peticio (encara que cada consulta
   individual continui trigant 8 ms, ara n'hi ha moltes mes per peticio).

8. La latencia p95 puja: 94 ms -> 280 ms.

9. KEDA detecta mes latencia o mes peticions per replica i escala:
   4 -> 9 repliques.

10. MES REPLIQUES EMPITJOREN LA CACHE: mes pods, cadascun amb menys
    peticions, patrons d'acces mes dispersos, i mes pods acumulant
    la fuita en paral·lel.

    ES UN CICLE QUE ES REALIMENTA.

# 1. Confirmar els OOMKilled i la seva frequencia
kubectl get pods -n rutas-norte-pro -l app=api-reserves \
  -o custom-columns='NOM:.metadata.name,REINICIS:.status.containerStatuses[0].restartCount,ULTIM:.status.containerStatuses[0].lastState.terminated.reason'

NOM                             REINICIS   ULTIM
api-reserves-7c9d4f8b6d-2mkjp   3          OOMKilled
api-reserves-7c9d4f8b6d-4nqzx   2          OOMKilled
api-reserves-7c9d4f8b6d-7wtrv   0          <none>

# 2. Confirmar el creixement monoton de la memoria (la prova definitiva)
# A Prometheus:
#   container_memory_working_set_bytes{namespace="rutas-norte-pro", container="api"}
# Rang: 30 dies.
#
# Si la linia PUJA I NO BAIXA MAI, ni tan sols a les valls nocturnes,
# es una fuita. Si baixa a les nits, es comportament normal del GC.

# 3. Comprovar la configuracio del heap de Node.js
kubectl get deployment api-reserves -n rutas-norte-pro \
  -o jsonpath='{.spec.template.spec.containers[0].env[?(@.name=="NODE_OPTIONS")].value}{"\n"}'

# 4. Veure la composicio de la memoria del proces
kubectl exec -n rutas-norte-pro api-reserves-7c9d4f8b6d-7wtrv -c api -- \
  node -e "const m = process.memoryUsage();
    console.log('rss:', (m.rss/1048576).toFixed(0), 'MB');
    console.log('heapTotal:', (m.heapTotal/1048576).toFixed(0), 'MB');
    console.log('heapUsed:', (m.heapUsed/1048576).toFixed(0), 'MB');
    console.log('external:', (m.external/1048576).toFixed(0), 'MB');
    console.log('arrayBuffers:', (m.arrayBuffers/1048576).toFixed(0), 'MB');"

rss: 1412 MB
heapTotal: 1180 MB
heapUsed: 1094 MB
external: 89 MB
arrayBuffers: 34 MB

# 5. Investigar Redis: que ha canviat?
kubectl exec -n rutas-norte-pro redis-cache-0 -- redis-cli INFO stats | grep -E "keyspace|expired|evicted"
kubectl exec -n rutas-norte-pro redis-cache-0 -- redis-cli INFO memory | grep -E "used_memory_human|maxmemory"
kubectl exec -n rutas-norte-pro redis-cache-0 -- redis-cli DBSIZE

# 6. Correlacionar reinicis amb caigudes de la taxa d'encerts.
# A Grafana, superposar:
#   - kube_pod_container_status_restarts_total{container="api"}
#   - redis_keyspace_hits_total / (hits + misses)
#
# Si cada reinici coincideix amb una caiguda de la taxa d'encerts,
# la cadena causal queda CONFIRMADA.

# 7. Capturar una instantania del heap per trobar la fuita
kubectl exec -n rutas-norte-pro api-reserves-7c9d4f8b6d-7wtrv -c api -- \
  kill -USR2 1
# (requereix que l'aplicacio tingui el gestor de heapdump)

// EL PATRO SOSPITOS
const cacheRutes = new Map();          // <- Sense limit de mida

app.get('/rutes', async (req, res) => {
  const clau = `${req.query.origen}:${req.query.desti}:${req.query.data}`;
  if (cacheRutes.has(clau)) return res.json(cacheRutes.get(clau));
  const rutes = await consultarRutes(req.query);
  cacheRutes.set(clau, rutes);         // <- CREIX PER SEMPRE
  res.json(rutes);
});

# 1. Pujar el limit de memoria per aturar els OOMKilled mentre
#    s'investiga. NO es una solucio: es un pedac.
resources:
  requests:
    memory: 800Mi
  limits:
    memory: 2560Mi     # De 1600Mi a 2560Mi
env:
  # I ajustar el heap coherentment: 65 % de 2560 = 1664
  - name: NODE_OPTIONS
    value: "--max-old-space-size=1664"

# 2. Reinici ordenat de totes les repliques per tornar al punt de partida
kubectl rollout restart deployment/api-reserves -n rutas-norte-pro

// Substituir el Map sense limit per una cache LRU acotada
const { LRUCache } = require('lru-cache');

const cacheRutes = new LRUCache({
  // SOSTRE DUR: 500 entrades. Amb ~50 KB per entrada, uns 25 MB maxim.
  max: 500,
  // TTL de 5 minuts: els horaris no canvien, pero acota el creixement.
  ttl: 1000 * 60 * 5,
  // Sostre per mida tambe, per si alguna entrada es enorme
  maxSize: 50 * 1024 * 1024,   // 50 MB
  sizeCalculation: (valor) => JSON.stringify(valor).length,
  updateAgeOnGet: false,
});

Cache en memoria del proces:
  + Mes rapida (0,001 ms davant d'1 ms de Redis)
  - Es duplica a cada replica: 9 repliques = 9 copies de les mateixes dades
  - Es perd a cada reinici
  - Fragmenta la taxa d'encerts: cada replica cacheja el seu
  - Es la causa d'aquesta fuita

Cache a Redis:
  + Compartida entre TOTES les repliques: molt millor taxa d'encerts
  + Sobreviu als reinicis
  + Un sol punt on ajustar TTL i politica d'expulsio
  - 1 ms de latencia de xarxa

RECOMANACIO: eliminar la cache en memoria i fer servir nomes Redis.
El mil·lisegon de diferencia es irrellevant davant del pressupost de
latencia de 300 ms, i elimina la fuita, la fragmentacio i el problema
dels reinicis d'una vegada.

# ALERTA 1: creixement monoton de memoria (la que hauria detectat aixo
# el dia 3, no el dia 21).
# deriv() calcula el pendent: si es positiu durant 6 hores seguides,
# la memoria nomes puja.
deriv(
  container_memory_working_set_bytes{namespace="rutas-norte-pro", container="api"}[6h]
) > 0

# ALERTA 2: qualsevol OOMKilled
increase(kube_pod_container_status_restarts_total{namespace="rutas-norte-pro"}[1h]) > 0
and on(pod, container)
kube_pod_container_status_last_terminated_reason{reason="OOMKilled"} == 1

# ALERTA 3: caiguda de la taxa d'encerts de la cache
(
  rate(redis_keyspace_hits_total[10m])
  /
  (rate(redis_keyspace_hits_total[10m]) + rate(redis_keyspace_misses_total[10m]))
) < 0.85

export const options = {
  scenarios: {
    resistencia: {
      executor: 'constant-arrival-rate',
      rate: 100,
      timeUnit: '1s',
      duration: '8h',            // VUIT HORES de carrega constant
      preAllocatedVUs: 100,
      maxVUs: 300,
    },
  },
};

# Si la memoria puja i NO baixa en 8 hores de carrega CONSTANT, hi ha fuita.
container_memory_working_set_bytes{namespace="rutas-norte-pre", container="api"}

# Si les connexions a PostgreSQL creixen sense alliberar-se, hi ha fuita de connexions.
pg_stat_activity_count{datname="reserves"}

# Si la latencia p95 creix un 5 % cada hora, hi ha degradacio progressiva.
histogram_quantile(0.95, sum(rate(api_reserves_duracio_segons_bucket[10m])) by (le))