Metrics refresh full-scans okapi_outbox (COUNT(*) GROUP BY status incl. 7 days of DELIVERED) every 15s per instance

Aberta
  • Algo errado?
#136 0 comentários 0 reações 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 1 dia

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
4/5
Tempo estimado
1-2 dias
Facilidade para iniciantes
42/100
Tipo de issue
Refatoração
Clareza
Razoavelmente clara
Status de atividade
Ativa
Stack de tecnologia
kotlin, mysql, postgresql
Domínio
databases, observability

Direção de pesquisa

Start in MicrometerOutboxMetrics, where the refresh runs the two queries, and in OutboxStore.countByStatuses and findOldestCreatedAt, which hold the GROUP BY status SQL. Decide which statuses the metrics need, then rewrite the oldest-per-status lookup as an index-ordered LIMIT 1 query per status. Done when the queries no longer scan DELIVERED rows and the metrics tests still pass on both PostgreSQL and MySQL.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

enhancement

Severity: Medium (performance) · Area: okapi-micrometer MicrometerOutboxMetrics, OutboxStore.countByStatuses/findOldestCreatedAt · Found in: code review of main @ e5630a1

Problem

Every metrics refresh runs two queries per instance, every 15 s by default:

SELECT status, COUNT(*) FROM okapi_outbox GROUP BY status;
SELECT status, MIN(created_at) FROM okapi_outbox WHERE status IN (?,?,?) GROUP BY status;
  • COUNT(*) ... GROUP BY status has to visit every row. The table keeps 7 days of DELIVERED rows by default (purger retention), which is ~60 M rows at 100 msg/s. N application instances each run this full scan every 15 s.
  • The MIN(created_at) query is index-friendly on MySQL (loose index scan), but Postgres before v18 has no skip scan. GROUP BY status with IN can scan the whole (status, created_at) index, again dominated by DELIVERED rows nobody alerts on.

Load grows with retention × throughput × instance count, on the same primary that serves the application's writes.

Suggested fix

  • Restrict both queries to the statuses that matter operationally (PENDING, FAILED). DELIVERED count/lag is rarely useful, and when it is, it can come from the counters.
  • Compute oldest-per-status with per-status index-ordered lookups, e.g. (SELECT created_at FROM okapi_outbox WHERE status='PENDING' ORDER BY created_at LIMIT 1), which costs O(log n) on both databases.
  • Optionally report DELIVERED from planner estimates or drop it.
Linguagem predominante
Kotlin
Estrelas
14
Forks
0
Merge médio
9h 54min
PRs com merge (30d)
11

Preparar o ambiente

Este projeto não oferece contêiner de desenvolvimento, Dockerfile nem guia de contribuição, então a configuração fica por sua conta: comece pelo README e veja nosso guia da primeira contribuição para os passos gerais.

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de softwaremill/okapi

Todas as issues de softwaremill/okapi

Issues semelhantes

Mais issues de Kotlin

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.