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

Abierto
  • ¿Algo no está bien?
#136 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
1-2 días
Aptitud para principiantes
42/100
Tipo de issue
Refactorización
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
kotlin, mysql, postgresql
Área
databases, observability

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.
Lenguaje dominante
Kotlin
Estrellas
14
Forks
0
Merge medio
9 h 54 min
PR fusionados (30 d)
11

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de softwaremill/okapi

Todos los issues de softwaremill/okapi

Issues similares

Más issues de Kotlin

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.