a. Visão geral

"Meça primeiro" é o hábito mais útil em design de sistemas. Antes de acrescentar um cache, uma réplica ou mais dez servidores, você precisa saber quanta carga o sistema atual aguenta, onde ele quebra e por quê. Chutar é como times passam um mês construindo um cache para um serviço cujo limite real era um pool de 10 conexões. Neste lab você trata o catalog como uma caixa-preta, com um gerador de carga na frente (o k6) e alguns medidores dentro (o Actuator), e produz o gráfico mais importante da disciplina: latência contra throughput.

Antes de começar

docker compose version        # Docker Compose v2.x (or newer)
java -version                 # 21 or newer
mvn -v                        # Apache Maven 3.9+
k6 version                    # k6 v1.0+
uv --version                  # uv (runs the Python helper scripts)

Estado inicial — o fim do lab 1, com a stack rodando (docker compose up -d, catalog saudável):

📁 boxoffice/
├──  docker-compose.yaml        # db + catalog (port 8082)
├──  load/hello.js  load/smoke.js
├──  results/lab0.md  results/lab1.md
├──  scripts/check-env.sh
└── 📁 services/catalog/          # the service of lab 1

Slides

Clique nos slides e use ← → para navegar; F abre em tela cheia e P abre a visão do apresentador, com as notas. Abrir os slides em uma nova aba

Antes de medir: uma hipótese

O playground roda o mesmo experimento em segundos. Forme uma hipótese primeiro e depois confira-a contra o serviço real.

Experimente: o cenário monolith abaixo começa com o perfil breakpoint — a carga cresce até algo ceder. Observe qual componente fica vermelho primeiro e como o p99 se comporta logo antes. Depois anote o seu palpite para o catalog: "ele vai quebrar em cerca de ___ req/s porque ___ satura primeiro".

1. Modelo de carga fechado ou aberto?

No lab 0, cada usuário virtual (VU) mandava uma requisição, esperava a resposta e mandava a próxima. Esse é um modelo fechado: quando o servidor fica lento, o gerador de carga fica lento junto, e o teste educadamente para de pressionar. Fãs reais não esperam uns pelos outros: às 10:00 eles chegam na taxa em que chegam. Esse é um modelo aberto.

2. Os scripts

O teste de carga mantém uma taxa de chegada constante (RATE) por um tempo fixo, com uma mistura realista: 80% de detalhes de evento e 20% de listagens por cidade.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45

// Lab 2: load test with an OPEN workload model. k6 starts RATE new requests per second,
// whether or not the previous ones have finished, like real fans arriving at a website.
//   k6 run -e RATE=100 -e DURATION=1m load/load.js
import http from 'k6/http';
import { check } from 'k6';

const BASE_URL = __ENV.BASE_URL || 'http://localhost:8082';
const RATE = Number(__ENV.RATE || 50);              // requests (iterations) per second
const DURATION = __ENV.DURATION || '1m';
const LIST_SHARE = Number(__ENV.LIST_SHARE || 0.2); // 20% listings, 80% event details
const CITIES = ['São Paulo', 'Rio de Janeiro', 'Belo Horizonte', 'Porto Alegre', 'Curitiba',
  'Salvador', 'Recife', 'Fortaleza', 'Brasília', 'Manaus'];

export const options = {
  scenarios: {
    open: {
      executor: 'constant-arrival-rate',
      rate: RATE,
      timeUnit: '1s',
      duration: DURATION,
      preAllocatedVUs: Math.max(20, RATE),   // VUs ready to start requests
      maxVUs: Math.max(200, RATE * 10),      // k6 may add more if requests get slow
    },
  },
  summaryTrendStats: ['avg', 'med', 'p(95)', 'p(99)', 'max'],
  thresholds: {
    http_req_failed: ['rate<0.01'],
    'http_req_duration{name:detail}': ['p(99)<500'],
    'http_req_duration{name:list}': ['p(99)<1000'],
  },
};

export default function () {
  if (Math.random() < LIST_SHARE) {
    const city = CITIES[Math.floor(Math.random() * CITIES.length)];
    const page = Math.floor(Math.random() * 5);
    const res = http.get(`${BASE_URL}/catalog/events?city=${encodeURIComponent(city)}&page=${page}`,
      { tags: { name: 'list' } });
    check(res, { 'list is 200': (r) => r.status === 200 });
  } else {
    const id = 1 + Math.floor(Math.random() * 200000);
    const res = http.get(`${BASE_URL}/catalog/events/${id}`, { tags: { name: 'detail' } });
    check(res, { 'detail is 200': (r) => r.status === 200 });
  }
}

O teste de estresse sobe uma escada de taxas além do joelho, segura o pico e depois volta a uma taxa baixa. A pergunta não é só "onde quebra?", mas "ele se recupera sozinho quando a carga vai embora?".

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51

// Lab 2: stress test. Climb a staircase of arrival rates past the knee, then come back
// down: does the service recover by itself when the load drops?
//   k6 run -e PEAK=600 load/stress.js
import http from 'k6/http';
import { check } from 'k6';

const BASE_URL = __ENV.BASE_URL || 'http://localhost:8082';
const PEAK = Number(__ENV.PEAK || 600);             // highest arrival rate (req/s)
const LIST_SHARE = Number(__ENV.LIST_SHARE || 0.2);
const CITIES = ['São Paulo', 'Rio de Janeiro', 'Belo Horizonte', 'Porto Alegre', 'Curitiba',
  'Salvador', 'Recife', 'Fortaleza', 'Brasília', 'Manaus'];

const step = (fraction, duration) => ({ target: Math.round(PEAK * fraction), duration });

export const options = {
  scenarios: {
    staircase: {
      executor: 'ramping-arrival-rate',
      startRate: 10,
      timeUnit: '1s',
      preAllocatedVUs: 50,
      maxVUs: 2000,
      stages: [
        step(0.25, '30s'), step(0.25, '30s'),   // warm-up and 1/4 of the peak
        step(0.50, '30s'), step(0.50, '30s'),
        step(0.75, '30s'), step(0.75, '30s'),
        step(1.00, '30s'), step(1.00, '1m'),    // peak, held longer
        step(0.25, '15s'), step(0.25, '1m'),    // back down: recovery?
      ],
    },
  },
  summaryTrendStats: ['avg', 'med', 'p(95)', 'p(99)', 'max'],
  thresholds: {
    http_req_failed: ['rate<0.05'],
    // a breakpoint test would abort here: { threshold: 'p(99)<2000', abortOnFail: true }
    http_req_duration: ['p(99)<2000'],
  },
};

export default function () {
  if (Math.random() < LIST_SHARE) {
    const city = CITIES[Math.floor(Math.random() * CITIES.length)];
    const res = http.get(`${BASE_URL}/catalog/events?city=${encodeURIComponent(city)}`,
      { tags: { name: 'list' }, timeout: '10s' });
    check(res, { 'list is 200': (r) => r.status === 200 });
  } else {
    const id = 1 + Math.floor(Math.random() * 200000);
    const res = http.get(`${BASE_URL}/catalog/events/${id}`, { tags: { name: 'detail' }, timeout: '10s' });
    check(res, { 'detail is 200': (r) => r.status === 200 });
  }
}

3. Observe por dentro

O k6 vê o serviço de fora. Para descobrir por que a latência cresce, você precisa de medidores de dentro. O Spring Boot Actuator já os publica:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

#!/usr/bin/env bash
# Lab 2: print, once per second, how many requests are INSIDE the service right now.
#   bash scripts/watch-metrics.sh http://localhost:8082
URL=${1:-http://localhost:8082}
metric() {   # metric <name>: current value of an actuator metric
  curl -s "$URL/actuator/metrics/$1" | jq -r '.measurements[0].value // "?"'
}
printf '%-8s %13s %10s %11s\n' time busy_threads db_active db_pending
while true; do
  printf '%-8s %13s %10s %11s\n' "$(date +%T)" \
    "$(metric tomcat.threads.busy)" \
    "$(metric hikaricp.connections.active)" \
    "$(metric hikaricp.connections.pending)"
  sleep 1
done

Mantenha três terminais abertos durante todo teste: o k6, bash scripts/watch-metrics.sh e docker stats (CPU do catalog e do db).

Você deve ver uma linha por segundo (na sobrecarga, uma a cada poucos segundos: a requisição que lê as métricas também espera uma thread livre do Tomcat). Em repouso, busy_threads vale 1 (a requisição que lê a métrica); sob carga ela segue a Lei de Little, e na sobrecarga o pool enche (linhas de uma execução deste lab, a 50, 400 e 600 req/s):

time      busy_threads  db_active  db_pending
03:43:21           1.0        0.0         0.0
03:45:19          12.0       10.0         3.0
03:46:15         200.0        9.0       190.0

4. Encontre o joelho

Rode o load.js com taxas crescentes, um minuto cada, e salve cada resumo. O script de varredura cuida da contabilidade (e faz um aquecimento antes: uma JVM fria estragaria o primeiro ponto):

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

#!/usr/bin/env bash
# Lab 2: run load.js once per arrival rate and save one k6 summary per run.
#   bash scripts/sweep.sh 25 50 100 150 200 300 400
# Then:  uv run scripts/summarize.py results/lab2/rate-*.json
set -euo pipefail
OUT=${OUT:-results/lab2}
DURATION=${DURATION:-1m}
mkdir -p "$OUT"
echo ">>> warm-up: 30 s at RATE=$1 (not recorded)"
k6 run -q -e RATE="$1" -e DURATION=30s load/load.js > /dev/null || true
for rate in "$@"; do
  echo ">>> RATE=$rate req/s for $DURATION"
  # || true: a run that crosses a threshold still produces a summary; keep sweeping
  k6 run -q -e RATE="$rate" -e DURATION="$DURATION" \
     --summary-export "$OUT/rate-$rate.json" load/load.js > /dev/null || true
  sleep 10   # let queues drain before the next step
done

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50

# /// script
# requires-python = ">=3.12"
# dependencies = []
# ///
"""Turn k6 --summary-export files into one Markdown table (one row per file).

    uv run scripts/summarize.py results/lab2/rate-*.json

The block above is inline script metadata (PEP 723): uv reads it and runs the
script with a suitable Python, no virtual environment to manage.
"""
import json
import re
import sys


def ms(metric, stat):
    value = metric.get(stat) if metric else None
    return f"{value:.1f}" if isinstance(value, (int, float)) else "–"


def row(path):
    m = json.load(open(path))["metrics"]
    offered = re.search(r"rate-(\d+)", path)
    dur = m.get("http_req_duration", {})
    failed = m.get("http_req_failed", {}).get("value", 0)
    dropped = m.get("dropped_iterations", {}).get("count", 0)
    return [
        offered.group(1) if offered else path,
        f"{m['http_reqs']['rate']:.0f}",
        ms(dur, "med"), ms(dur, "p(95)"), ms(dur, "p(99)"),
        ms(m.get("http_req_duration{name:detail}"), "p(99)"),
        ms(m.get("http_req_duration{name:list}"), "p(99)"),
        f"{failed * 100:.1f}%",
        str(dropped),
        str(m.get("vus_max", {}).get("value", "–")),
    ]


def sort_key(path):
    n = re.search(r"rate-(\d+)", path)
    return int(n.group(1)) if n else 0


header = ["offered (req/s)", "throughput (req/s)", "p50 (ms)", "p95 (ms)", "p99 (ms)",
          "p99 detail", "p99 list", "errors", "dropped", "max VUs"]
print("| " + " | ".join(header) + " |")
print("|" + "|".join("---:" for _ in header) + "|")
for path in sorted(sys.argv[1:], key=sort_key):
    print("| " + " | ".join(row(path)) + " |")

docker compose up -d                       # catalog + db from lab 1
bash scripts/sweep.sh 50 100 200 300 400 500 600
uv run scripts/summarize.py results/lab2/rate-*.json

O sweep.sh imprime uma linha por etapa (>>> warm-up: 30 s at RATE=50 (not recorded), depois >>> RATE=50 req/s for 1m, …) e leva cerca de 10 minutos para sete taxas. As etapas além do joelho também imprimem level=error msg="thresholds on metrics ... have been crossed": os limites de latência do load.js falharam, o que é esperado ali — o resumo é salvo mesmo assim. Em seguida, o summarize.py imprime uma tabela Markdown como a de baixo — cole-a em results/lab2.md.

Uma execução de exemplo num notebook (catalog limitado a 1 CPU, pool de 10 conexões):

Acima de 500 req/s os números pulam de uma execução para outra — sinal de que o serviço está sobrecarregado e são as filas que decidem o resultado, não o código.

Como ler:

• Abaixo do joelho, o throughput é igual à taxa oferecida e o p99 é praticamente plano: as requisições raramente esperam umas pelas outras.
• No joelho, um recurso chega a ~100% de ocupação. Pequenos aumentos de carga produzem aumentos grandes de latência — a curva de filas da aula 2 (W ≈ S / (1 − ρ)).
• Além do joelho, o throughput deixa de acompanhar a taxa oferecida, aparece dropped_iterations (o k6 ficou sem VUs para manter a taxa) e o p99 é medido em segundos. Os usuários já foram embora.

5. Verificação da Lei de Little

A Lei de Little vale para qualquer sistema estável²: L = λ × W — o número médio de requisições dentro (L) é igual à taxa de chegada (λ) vezes o tempo médio que cada uma passa dentro (W). Aplique-a a duas fronteiras:

1. O serviço inteiro: L deve bater com tomcat.threads.busy. A 300 req/s com latência média de 10 ms, L = 300 × 0.010 = 3 threads ocupadas.
2. O pool do banco: cada requisição segura uma conexão durante o seu tempo de banco. O pool é um servidor com 10 vagas, então ele satura quando λ × (database time per request) = 10.

Essa segunda linha prevê o joelho. Meça o tempo de banco por requisição com um usuário (lab 1): se a mistura dá em média ~8 ms de banco por requisição sem carga, o pool permitiria 10 / 0.008 ≈ 1,250 req/s. O joelho que você mediu é bem mais baixo — porque sob carga as consultas ficam mais lentas (o banco e a única CPU do catalog também estão ocupados), e cada requisição segura sua conexão por mais tempo. Olhe o watch-metrics.sh perto do joelho: db_active fica em 10 e db_pending começa a crescer. O pool está cheio; as requisições fazem fila por ele.

6. Mude o gargalo de lugar

Mude uma variável e meça de novo. O tamanho do pool é configurável sem rebuild (DB_POOL_SIZE, ligado no lab 1):

DB_POOL_SIZE=30 docker compose up -d catalog        # recreate catalog with a bigger pool
OUT=results/lab2-pool30 bash scripts/sweep.sh 50 100 200 300 400 500 600
uv run scripts/summarize.py results/lab2-pool30/rate-*.json

Compare as duas tabelas. Em geral o joelho sobe, mas não para sempre: com 30 conexões, o próximo recurso satura — a única CPU do catalog ou o próprio PostgreSQL (observe o docker stats). Um pool maior também tem custo: cada conexão é um processo no PostgreSQL, e no lab 6 três serviços × três réplicas × 30 conexões passariam de max_connections. Otimizar um recurso sempre muda o gargalo de lugar; o trabalho é saber para onde ele foi.

7. Estresse: além do joelho e de volta

docker compose up -d catalog       # back to the default pool (10): PEAK=600 is past its knee
K6_WEB_DASHBOARD=true K6_WEB_DASHBOARD_EXPORT=results/lab2-stress.html \
  k6 run -e PEAK=600 load/stress.js

Abra http://localhost:5665 enquanto ele roda: o dashboard web do k6 plota a taxa de requisições, os percentis de latência e os VUs ao longo do tempo; o relatório HTML é salvo no fim. Procure três momentos:

1. O joelho na subida: o p95 sai do chão.
2. O pico: os VUs sobem em direção a maxVUs — o k6 precisa de mais usuários simultâneos para manter a taxa porque cada requisição demora mais (a Lei de Little de novo, do lado do cliente).
3. A recuperação: depois da queda para 25% do pico, quantos segundos até o p95 voltar ao normal? Um serviço que se recupera sozinho é estável; um que continua lento (filas que nunca esvaziam, um coletor de lixo que nunca alcança) precisa de load shedding — tema dos labs 3 e 9.

Meça

Registre tudo em results/lab2.md:

# Lab 2 — catalog under load

Setup: catalog 1 CPU / 768 MB, Hikari pool = 10, PostgreSQL 17, k6 open model (80% detail, 20% list)

## Sweep (pool = 10)
<paste the table printed by summarize.py>

## Sweep (pool = 30)
<paste the table>

## Knee and capacity
- Knee (pool 10): ____ req/s — capacity with p99 < 300 ms: ____ req/s
- Knee (pool 30): ____ req/s — capacity with p99 < 300 ms: ____ req/s
- Bottleneck at the knee (evidence from watch-metrics / docker stats): ____

## Little's Law
| Offered (req/s) | avg latency (s) | λ × W | busy threads (measured) | db_active (measured) |
|---:|---:|---:|---:|---:|
|  100 |  |  |  |  |
|  300 |  |  |  |  |

## Stress test
- Peak reached: ____ req/s; p95 at the peak: ____ ms; dropped iterations: ____
- Recovery time after the drop: ____ s

## Hypothesis check
- My playground hypothesis was: ____ . It was right / wrong because ____ .

Solução de problemas

Limpeza

docker compose up -d catalog     # if you changed DB_POOL_SIZE, recreate catalog with the default (10)
docker compose down              # when you are done for the day (data is kept)

Guarde results/lab2* (os resumos JSON e o seu results/lab2.md): o lab 3 compara com eles. O relatório HTML é ignorado pelo Git de propósito (é grande).

Entrega

• load/load.js, load/stress.js, scripts/sweep.sh, scripts/summarize.py e scripts/watch-metrics.sh no seu repositório.
• Duas varreduras (pool 10 e pool 30) com as tabelas em results/lab2.md, o joelho e a capacidade de cada uma.
• A tabela da Lei de Little com pelo menos duas taxas, comparada com os medidores.
• O relatório HTML do teste de estresse (results/lab2-stress.html, sem commit) e os seus três momentos descritos.
• Um parágrafo: qual é o gargalo do catalog, e qual é a sua evidência?
• Repositório com a tag lab2; quiz respondido.

Estado final

📁 boxoffice/
├──  load/load.js                 # open-model load test (RATE, DURATION, LIST_SHARE)
├──  load/stress.js               # staircase past the knee and back
├──  scripts/sweep.sh             # one load.js run per rate
├──  scripts/summarize.py         # k6 summaries -> Markdown table (uv run)
├──  scripts/watch-metrics.sh     # Tomcat threads and Hikari pool, once per second
└── 📁 results/lab2/  results/lab2-pool30/  results/lab2.md

Nenhum serviço mudou: a stack ainda é db + catalog.

Próximo: Lab 3 — Borda, em que uma réplica vira três.