Relatório de melhorias de performance

Este texto explica, em linguagem de produto, por que a tela de simulação “caía” no ambiente de desenvolvimento, o que o usuário via, e o que mudou no fluxo pesquisa → estratégia → simulação. Os detalhes de engenharia vêm depois de cada analogia, com trechos do código que entrou nas PRs #371 a #421.

O problema real

O Pricing não “ficava lento”. Ele morria. Uma pessoa pedia uma simulação grande — dezenas de milhares de produtos de farmácia, preços de concorrentes, regras de margem. O servidor tentava carregar essa lista inteira na memória, várias vezes ao mesmo tempo, enquanto a tela perguntava a cada 3 segundos “já terminou?”. Cada pergunta puxava de novo a lista completa (~21 MB). O computador do servidor só tem 2 GB. Quando a conta passava disso, o processo era morto. Para quem estava na tela, aparecia um erro genérico de gateway (502 ou 504): a página branca, o overlay travado, a simulação “perdida”.

Athena

O “depósito” de dados de preço e pesquisa. A simulação pede um recorte enorme; se o recorte vier inteiro para a memória, o servidor enche.

Pod / servidor

Uma instância só do Pricing, com 2 GB de RAM. Não há cópia de reserva: se essa instância cai, ninguém da equipe usa o DEV até ela voltar.

502 / 504

A porta da frente (o balanceador) corta a ligação porque o servidor não responde a tempo, ou porque o processo já morreu. Não é uma mensagem de negócio (“simulação grande demais”); é a porta fechando na cara.

Fluxo ponta a ponta

No Radar, gerar preço não é um botão isolado. É um ciclo: a pessoa sobe pesquisas de mercado, monta a estratégia e só então pede a simulação. Cada etapa já conversa com o mesmo servidor.

flowchart LR
  P["1. Pesquisa<br/>Importa planilhas de mercado"]
  E["2. Estratégia<br/>Regras e competitividade"]
  S["3. Simulação<br/>Clica em gerar"]
  A["4. Acompanhar<br/>A cada 3s: já terminou?"]
  C["5. Catálogo<br/>Tabela de ~21 mil produtos"]
  P --> E --> S --> A --> C

Por trás desses cliques, o pedido atravessa o navegador, a API Nuxt, o Athena e o Mongo. Tudo isso acontece no mesmo processo Node — não existe um “operário” separado só para calcular.

flowchart LR
  N["Navegador<br/>Clique e espera"]
  API["API Nuxt<br/>Recebe, calcula e responde"]
  ATH["Athena<br/>Recorte de mercado"]
  MON["Mongo<br/>Grava produtos"]
  JSON["JSON da tela<br/>Lista da tabela"]
  N --> API
  API --> ATH
  API --> MON
  API --> JSON

O que quebrava o servidor

Pense na memória como uma mesa de 2 m². A lista de uma simulação é uma pilha de papéis de ~21 MB. O sistema antigo deixava três pilhas na mesa ao mesmo tempo: a que veio do Athena, a cópia já “enriquecida” com concorrente, e a cópia que o banco montava para gravar. Enquanto isso, a tela pedia de novo a pilha inteira a cada 3 segundos. A mesa caía.

flowchart LR
  subgraph antes["Antes — tudo na mesa"]
    direction TB
    a1["Athena inteiro"] --> a2["Lista enriquecida"]
    a2 --> a3["Documento no Mongo"]
    a3 --> a4["Poll 21 MB a cada 3s"]
  end
  subgraph depois["Depois — uma fatia"]
    direction TB
    d1["Athena página a página"] --> d2["Lote de 1.000"]
    d2 --> d3["Poll 115 B"]
    d3 --> d4["Catálogo só no ready"]
  end

O dia em que a memória subiu 1,7 GB em 5 minutos

Em 08/09/2026 o servidor estava calmo de manhã (~90 MB). Em cinco minutos, ao materializar um recorte grande do Athena, passou de 200 MB para quase 2 GB — o teto da máquina. O coletor de lixo do Node passou mais de 99% do tempo tentando limpar. Na mesma hora: 27 respostas 504, 4 respostas 502, 12 erros de conexão. No dia anterior, o pico tinha sido 78 MB e zero reinícios. Não foi um vazamento lento; foi um único passo grande demais.

Por isso a restrição de máquina importa: não dá para “caber mais um pouco”. Se estoura, a equipe inteira perde o DEV.

Oito jeitos de a mesa cair

Não era um bug só. Era uma sequência: cada camada assumia que a anterior cabia. Abaixo, o sintoma na vida real e a causa técnica.

Como resolvemos

Sem aumentar a máquina e sem um worker dedicado, a linha foi: não guardar o que não precisa estar vivo, recusar o que não cabe e não tratar “ocupado” como simulação quebrada. Cada PR fecha uma camada. A seguinte só faz sentido depois da anterior — como fechar torneiras de uma caixa d’água que transbordava.

flowchart LR
  a["#371 Athena<br/>Página a página, 413 se não cabe"]
  b["#399 / #406<br/>Leitura, lotes, cerca de heap"]
  c["#417 Poll leve<br/>Já terminou? sem a tabela"]
  d["#418 Portaria<br/>Só entra quem cabe, 429"]
  e["#420 Fatias<br/>1.000 produtos por vez"]
  a --> b --> c --> d --> e

1. Não trazer o depósito inteiro para a sala

O Athena devolve o resultado em páginas de 1.000 linhas. O código antigo podia acumular a página crua e só depois converter — duas cópias vivas. Agora cada página é convertida na hora e a crua some. Se o recorte passar de 200 mil linhas, a API responde 413 (“isso não cabe; reduza lojas ou período”) em vez de morrer. O prazo da consulta inteira é 55 s, abaixo dos 60 s da porta da frente, para o erro chegar com mensagem, não como 504 mudo.

async function collectResults(client, queryExecutionId, mapRow, maxRows, deadline) {
  const results = [];
  do {
    const { rows } = parseResultSet(await client.send(pageCommand));
    if (results.length + rows.length > maxRows) {
      throw createError({
        statusCode: 413,
        statusMessage: `Athena: a query retornaria mais de ${maxRows} linhas`,
      });
    }
    for (const row of rows) {
      results.push(mapRow ? mapRow(row) : row);
    }
  } while (nextToken);
  return results;
}

2. Separar “já terminou?” de “mande a tabela”

A tela precisa saber se o cálculo acabou. Isso não exige 21 mil produtos. O poll passou a pedir view=progress: um recado de status. O catálogo só é montado uma vez, quando o status é ready — e mesmo aí, se outro cálculo pesado está no ar, o GET da tabela espera.

// O poll do cliente roda a cada 3s e não precisa do catálogo.
if (view === "progress") {
  return {
    status: "ready",
    stage: clustersProducts.processing_stage,
    clusters_products_by_period_id: clustersProducts._id,
    date: responseDate,
  };
}

rejectCatalogGetIfHeavyQueryBusy();
return runWithCatalogMaterializationLock(async () => {
  return JSON.stringify({ clusters, products, margin_tree, date });
});

const pollProgress = async () => {
  return callbacks.getSimulationData(simulationID, { view: "progress" });
};

let response = await pollProgress();
while (response.status !== "ready") {
  if (response.status === "failed") {
    throw new Error(response.message || "Falha no processamento da simulação.");
  }
  await wait(3000);
  response = await pollProgress();
}
await callbacks.getSimulationData(simulationID); // catálogo uma vez

3. Uma portaria na porta, não um “entra todo mundo”

O servidor só consegue um cálculo pesado com folga. Se cinco pessoas clicam juntas, as extras precisam ouvir “ocupado, tente de novo em instantes” — e a simulação delas não pode virar failed. A reserva da vaga acontece no mesmo instante do GET, antes de criar o documento. Sem isso, vários pedidos passavam na checagem “está livre?” e só depois tentavam ocupar, furando o teto.

export const reserveHeavyQueryJob = (label, maxPending) => {
  if (pendingCount() >= maxPending) {
    throw createError({
      statusCode: 429,
      statusMessage:
        "Servidor ocupado processando consultas pesadas. Tente novamente em instantes.",
      headers: { "Retry-After": "10" },
    });
  }
  const reservation = { id: ++reservationSeq, released: false };
  openReservations.add(reservation.id);
  return reservation;
};

Na tela, isso vira overlay de “ocupado” e a espera continua. Dois cliques em “gerar análise” não disparam dois cálculos: o segundo informa que o trabalho já está andando.

4. Cortar o trabalho em fatias de 1.000

Mesmo com a portaria, um único recorte grande ainda empilhava o grafo inteiro na hora de enriquecer e gravar. A correção é consumir a lista com splice: tira 1.000, enriquece, grava, descarta, pega os próximos. A mesa só vê um lote. Pesquisa de mercado precisa de um cuidado extra: o preço de um grupo não pode ser cortado no meio — primeiro monta o índice dos grupos, depois pagina os itens.

const batchSize = persistBatchSize();

while (productsFromCluster.length) {
  const batch = productsFromCluster.splice(0, batchSize);
  const { products: enriched, research_products } =
    await enrichClusterProductsWithCompetitorMarketAndResearch(
      clusters,
      batch,
      { economicGroup, allowInPlaceMutation },
    );
  await persistClusterItemBatch(enriched, clustersProductsId, processingRunId);
  await persistResearchProductBatch(
    research_products,
    clustersProductsId,
    processingRunId,
  );
}

O que mudou para quem usa a tela

O que os testes mostraram

Rodamos o ciclo real contra o DEV: cinco importações de pesquisa em paralelo, depois 5 simulações juntas, depois 10. Critério de sucesso para o dia a dia da equipe: zero erro 5xx e uma simulação “canário” respondendo 200. O poll usava o recado curto; a tabela de 21 MB só entrava no teste smoke, depois de pronta.

Quantas vezes a porta fechou (502)

Tradução: separar o “já terminou?” do catálogo tirou o 502 do uso normal e de 5 pessoas juntas. A portaria passou a recusar o excedente em vez de aceitar até cair. O que ainda matava o servidor era o pico de um único cálculo na hora de gravar — exatamente o que as fatias (#420) atacam. Essa parte já está no código, com 19 testes do serviço passando; não havia corrida de carga nova gravada no repositório depois desse merge.

Conclusão

As melhorias são camadas, não um interruptor. Recusar pedido extra não encolhe um cálculo; fatiar o cálculo não substitui a portaria. As duas juntas é que cabem nos 2 GB, sem máquina maior e sem um processo só para simulação.