Scheduler processes one batch per worker per tick: default throughput capped at <10 msg/s, backlog grows unbounded

オープン
  • 何か問題がありますか？
#132 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
3/5
見積もり時間
1〜2日
初心者へのやさしさ
52/100
issue の種類
バグ
明瞭さ
明確に書かれている
活発さ
活発
技術スタック
kotlin
領域
backend

調査の方向性

Start in the OutboxScheduler in okapi-core, where scheduleWithFixedDelay runs processNext(batchSize) once per worker per tick, and read processBatch to see how each tick's transaction is opened. Change it so the loop keeps draining while a batch comes back full, with one transaction per iteration and a time or iteration budget that still lets stop() return promptly. Done means a sustained high publish rate no longer backs up the queue under default settings, stop() stays responsive, and the existing tests pass; the issue also asks for a benchmark of sustained throughput.

索引モデルが issue の本文から書いたものです。

説明

bug critical

Severity: High (performance / unbounded backlog) · Area: okapi-core OutboxScheduler · Found in: code review of main @ e5630a1

Problem

Each scheduler tick has every worker call processNext(batchSize) exactly once, using scheduleWithFixedDelay. That puts a hard ceiling on throughput:

max throughput ≈ concurrency × batchSize / (interval + batch processing time)

With the defaults (concurrency = 1, batchSize = 10, interval = 1s) that is under 10 messages/second, regardless of how fast the DB and transport are. Any sustained publish rate above that grows the backlog without bound, and latency grows linearly with it. A burst of 100k messages takes about 3 hours to drain with the defaults, even when each batch takes milliseconds.

Raising interval to cut idle polling makes this worse. Raising batchSize makes transactions longer (see the related issues on gap locks and delivery inside the transaction).

Suggested fix

In processBatch, keep draining while the previous batch was full. Each iteration gets its own transaction, and the loop is bounded by a time or iteration budget so stop() stays responsive:

do {
    val n = transactionRunner.runInTransaction { outboxProcessor.processNext(config.batchSize) }
} while (n == config.batchSize && running.get() && !budgetExceeded())

That way the poll interval only governs idle latency, not peak throughput. The benchmarks should cover a sustained-rate scenario as well as fixed-backlog drains.

主要言語
Kotlin
スター
14
フォーク
0
平均マージ
14時間 16分
マージ済み PR（30日）
9

環境構築

このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

softwaremill/okapi のほかの issue

softwaremill/okapi の issue をすべて見る

似ている issue

Kotlin の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。