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

Ouverte
  • Quelque chose ne va pas ?
#136 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Personne n'a encore pris cette issue.

Évaluation

Difficulté
4/5
Temps estimé
1-2 jours
Accessibilité débutants
42/100
Type d'issue
Refactorisation
Clarté
Plutôt claire
Activité
Active
Stack technique
kotlin, mysql, postgresql
Domaine
databases, observability

Piste de recherche

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.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

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.
Langage dominant
Kotlin
Étoiles
14
Forks
0
Merge moyen
9 h 54 min
PR mergées (30 j)
11

Préparer son environnement

Ce projet ne fournit ni conteneur de développement, ni Dockerfile, ni guide de contribution : l'installation est à votre charge. Commencez par son README, et consultez notre guide de la première contribution pour les étapes générales.

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de softwaremill/okapi

Toutes les issues de softwaremill/okapi

Issues similaires

Plus d'issues Kotlin

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.