You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
docs(ui): publish a capacity & throughput operator doc
No user-facing doc surfaced capacity/throughput/concurrency numbers -- they existed only in
scattered code comments and the iterate-loop load-test harness output. Adds /docs/capacity as
the throughput/concurrency counterpart to the existing /docs/ams-sizing (CPU/RAM/disk), scoped
strictly to the numbers and where each comes from:
- AMS iterate-loop orchestration throughput, from the committed load-test harness
(packages/loopover-engine/docs/iterate-loop-load-test.md, #4913's tooling).
- Review-gate PR-processing concurrency caps (SWEEP_MAX_PRS/ISSUE_WAKE_MAX_PRS/MERGE_WAKE_MAX_PRS
from src/settings/agent-sweep.ts) and Cloudflare Queue consumer bounds (max_batch_size/
max_concurrency from wrangler.jsonc), both verified against their literal source values.
Closes#4914
description: Real throughput and concurrency numbers for AMS's iterate-loop and the review-gate's PR-processing queue, so an operator can plan for load instead of guessing.
4
+
---
5
+
6
+
Real throughput and concurrency numbers for AMS's iterate-loop and the review-gate's PR-processing
7
+
queue — the counterpart to [Resource sizing](/docs/ams-sizing) (CPU/RAM/disk), scoped strictly to
8
+
throughput/concurrency and where each number comes from.
9
+
10
+
## AMS: iterate-loop orchestration throughput
11
+
12
+
From the committed load-test harness (`packages/loopover-engine/docs/iterate-loop-load-test.md`,
13
+
built for #4913/#5224), measuring `runIterateLoop`'s own orchestration overhead under concurrent,
14
+
multi-tenant-like load with a 15ms simulated per-iteration driver latency:
description: "The recurring sweep's per-tick cap — sized for a sweep that re-runs every ~2 minutes, so a low steady-state budget compounds safely across ticks.",
43
+
},
44
+
{
45
+
title: "ISSUE_WAKE_MAX_PRS = 25",
46
+
description: "One-shot budget for an issue-linked wake event — a rarer trigger than a merge, so a larger one-time budget doesn't risk compounding across repeated events in one rate-limit window.",
47
+
},
48
+
{
49
+
title: "MERGE_WAKE_MAX_PRS = 15",
50
+
description: "One-shot budget for a merge-triggered wake — sized lower than the issue-wake budget because merges are a far more common trigger; a repeated-merge burst inside one rate-limit window must not compound the way the rarer issue-wake trigger safely can.",
51
+
},
52
+
]}
53
+
/>
54
+
55
+
## Review-gate: Cloudflare Queue consumer bounds
56
+
57
+
From `wrangler.jsonc`'s `loopover-jobs` queue consumer — Cloudflare Queues consumer-binding
58
+
attributes, read at `wrangler deploy` time (not runtime-configurable via `env.SOMETHING`):
59
+
60
+
<FeatureRow
61
+
items={[
62
+
{
63
+
title: "max_batch_size = 5",
64
+
description: "The most jobs one batch can bundle at once — bounds how many heavy sweep/backfill jobs land in a single delivery.",
65
+
},
66
+
{
67
+
title: "max_concurrency = 3",
68
+
description: "Bounded fan-out, sized to drain one heavy installation's worst sweep within the 2-minute cron interval without flooding that installation's own GitHub rate-limit bucket.",
69
+
},
70
+
]}
71
+
/>
72
+
73
+
<Calloutvariant="note"title="Re-tuning these for real multi-tenant volume">
74
+
`max_batch_size × max_concurrency` bounds the most jobs that can be in flight — each making
75
+
GitHub calls — at any one instant, kept comfortably under an installation's rate-limit headroom.
76
+
A genuinely multi-tenant volume model needs real production job-volume data (job rate, distinct-
77
+
installation count, GitHub rate-limit headroom actually observed) to re-derive against — re-tune
78
+
from a live dashboard/`audit_events` query when that data exists, not by guessing a bigger
79
+
number.
80
+
</Callout>
81
+
82
+
**Takeaways:**
83
+
84
+
- Iterate-loop's own orchestration overhead scales roughly linearly with concurrency — the
85
+
bottleneck at real scale is each attempt's actual coding-agent driver latency, not the loop's
86
+
scheduling/bookkeeping around it.
87
+
- The review-gate's PR-processing caps are deliberately asymmetric across trigger type
88
+
(`SWEEP_MAX_PRS`\<`MERGE_WAKE_MAX_PRS`\<`ISSUE_WAKE_MAX_PRS`) because each trigger recurs at a
89
+
different rate — a budget sized for a rare trigger would compound dangerously if applied to a
90
+
frequent one.
91
+
- Every number above was measured or verified directly against the source it's read from (the
92
+
committed load-test harness, or the literal constant/config value) — none are estimates.
93
+
94
+
See [Resource sizing](/docs/ams-sizing) for CPU/RAM/disk numbers, and the [AMS Cloud Readiness
95
+
milestone](https://github.com/JSONbored/loopover/milestone/28) for the per-tenant scheduling and
96
+
queue-fairness design work these numbers feed into.
{title: "Capacity and throughput — LoopOver docs"},
22
+
{
23
+
name: "description",
24
+
content:
25
+
"Real throughput and concurrency numbers for AMS's iterate-loop and the review-gate's PR-processing queue, so an operator can plan for load instead of guessing.",
26
+
},
27
+
{property: "og:title",content: "Capacity and throughput — LoopOver docs"},
28
+
{
29
+
property: "og:description",
30
+
content:
31
+
"Real throughput and concurrency numbers for AMS's iterate-loop and the review-gate's PR-processing queue, so an operator can plan for load instead of guessing.",
0 commit comments