[DRAFT] Optimize query-path caching/memoization by cjonas9 · Pull Request #1003 · stellar/stellar-rpc

cjonas9 · 2026-09-11T07:36:30Z

Superseded by #1060. GitHub auto-closed this PR as merged into bypass-jrpc2-marshal when the stack was reordered to put this change first; no code reached feature/full-history from here. The same commits are under review in #1060.

What

Adds latestMemo[T] in methods/latest_memo.go, an atomic pointer to a {seq, value} entry plus a miss mutex. A new ledger invalidates it by moving the key, so there is no ingestion hook.
This is used so that...

getLatestLedger memoizes its rendered response.** The fully rendered JSON is cached keyed by ledger sequence.
getNetwork and getVersionInfo also benefit from this, as getProtocolVersion now memoizes the result by sequence with the same latestMemo.

You can compare the optimized performance seen in coordinator runs here to the base perf measured in #1018. The results in the coordinator runs here include all recent optimization work -- XDR views adoption (#945, #962, #941, #1035, all validated by tests in #976, #982), as well as more recent tangential optimizations (see the stack, particularly #1036, 1037, and this PR).

Measurements

Handler-level, from the perf-eval go-bench leg on this branch (pubnet-sized ledger):

	time	B/op	allocs/op
GetLatestLedger, uncached	8.8 ms	11.2 MiB	40
GetLatestLedger, cached	1.06 µs	164 B	5

getNetwork over the pubnet sqlite fixture (BenchmarkLedgerReads harness; v1 sqlite / v2 hot). getVersionInfo tracks it within noise:

	time	B/op	allocs/op
before	4.2 ms / 4.4 ms	10.5 MB / 9.2 MB	103,000
header view read	175 µs / 264 µs	1.5 MB / 8.7 KB	~200
view + memo	10 µs / 13 µs	5 KB / 6 KB	~120

The memo row is getHealth cost. The 103K allocations per call were what made these endpoints fold under concurrency.

Tests

getLatestLedger: serves the memo until the ledger advances, an older view does not evict a newer render, 32 concurrent misses render once, errors are not memoized, and the rendered bytes are byte-equal to marshaling the response struct.
Protocol version: same memo behaviour, plus getNetwork doing one raw read across two requests.
BenchmarkGetLatestLedger gained cached and uncached rows.

Why

getLatestLedger, getNetwork and getVersionInfo are what SDKs and wallets poll continuously, and they were the first endpoints to buckle under load even though their answers change once per ledger. Proportionate to what they return, they were made needlessly expensive because every request touched the 2 MB latest ledger. This is a full decode for one field or a base64 render of the whole thing.

Additionally, the jhttp bridge added a client/server round trip that re-parsed multi-megabyte results, about 65% of end-to-end time. Anything that only changes when the ledger sequence changes can be memoized by sequence with no invalidation plumbing, and one memo shape covers every "fact about the latest ledger". The response-path fix belongs inside jrpc2 rather than in a parallel dispatcher, hence the fork.

Known limitations / additional notes

Depends on a jrpc2 fork. stellar-experimental/jrpc2@raw-message-passthrough is four commits ahead of upstream. Upstream, vendor or keep the fork is an open decision.
Supercedes jsonrpc: own the response envelope — one marshal, one write; the jhttp bridge retires #969 (own the response envelope, retire the bridge). Both remove the bridge round trip and only one should land. They perform the same on struct results; they differ on json.RawMessage results and in how the handler context is built.
simulateTransaction still has the old pattern. getLatestLedgerPreflightInfo full-decodes the latest ledger for three header fields. The same view read applies; left for a follow-up.
Per-handler memos, not one shared cache. getLatestLedger, getNetwork and getVersionInfo each hold their own. A shared one would need wiring through specs.go, and a getNetwork miss would then either trigger the 2 MB render or need per-field laziness.

github-actions · 2026-09-11T12:01:21Z

🧪 Performance Evaluation Test #11

Commit: 7af387ac1ed6 (cache-getLatestLedger)
Run: https://github.com/stellar/stellar-rpc/actions/runs/36772356967

✅ Backfill ingestion — verdict: ok

⏳ Backfill ingestion — `7af387ac1ed6`

Metric	Value
Ledgers ingested	120960 (`[64583552 -> 64704511]`)
Retention window	120960
Wall-clock (total)	2h41m9s
Ingest phase	2h14m4s
Bulk-load finalize phase	27m5s
Ledgers/sec (ingest)	15.0

✅ Endpoint load test — verdict: ok

🎯 Endpoint load test — `7af387ac1ed6`

Serial blast per endpoint (ramp-up 1m, duration 3m, error kill switch 75%, blaster aadc1a17595f) against the backfilled RPC (ledgers [64584266, 64705225], handoff wait 1351s).

Endpoint	Target RPS	Requests	Errors	p50 (ms)	p95 (ms)	p99 (ms)	p99.9 (ms)
getEvents	75	11224	7 (0.1%)	0.8	11.6	30.5	3909.6
getFeeStats	250	37493	0 (0.0%)	0.4	0.5	0.6	1.0
getHealth	250	37493	0 (0.0%)	0.4	0.5	0.6	1.2
getLatestLedger	15	2244	0 (0.0%)	7.2	10.7	25.1	33.2
getLedgers (limit=5)	3	440	0 (0.0%)	183.2	1417.2	1828.9	2061.3
getNetwork	100	14978	0 (0.0%)	0.5	0.6	0.7	3.5
getTransaction	75	11225	0 (0.0%)	5.8	12.8	20.2	27.2
getTransactions (limit=200)	10	1474	0 (0.0%)	21.3	321.0	384.3	453.1
getVersionInfo	100	14782	0 (0.0%)	0.4	0.5	0.6	3.3

getEvents results extended

Endpoint	Target RPS	Requests	Errors	p50 (ms)	p95 (ms)	p99 (ms)	p99.9 (ms)
getEvents/catch-up	3	460	0 (0.0%)	3.7	21.2	36.5	68.4
getEvents/deep-pager	17.25	2525	0 (0.0%)	0.7	21.2	159.1	1666.0
getEvents/deep-scan	2.25	356	2 (0.6%)	0.7	6.8	11.6	10002.4
getEvents/firehose	1.5	242	0 (0.0%)	0.7	2.5	4.5	23.5
getEvents/head-poll	36	5441	0 (0.0%)	0.8	7.0	11.2	67.6
getEvents/tail-poll	9	1278	5 (0.4%)	0.7	0.9	1069.1	10002.4
getEvents/transfer-watcher	6	922	0 (0.0%)	7.9	18.3	22.4	26.8

Performance Evaluation Test #10

🧪 Performance Evaluation Test #10

Commit: 190e08d28bb5 (cache-getLatestLedger)
Run: https://github.com/stellar/stellar-rpc/actions/runs/36183403938

✅ Backfill ingestion — verdict: ok

⏳ Backfill ingestion — `190e08d28bb5`

Metric	Value
Ledgers ingested	120960 (`[64496896 -> 64617855]`)
Retention window	120960
Wall-clock (total)	2h39m24s
Ingest phase	2h11m48s
Bulk-load finalize phase	27m36s
Ledgers/sec (ingest)	15.3

✅ Endpoint load test — verdict: ok

🎯 Endpoint load test — `190e08d28bb5`

Serial blast per endpoint (ramp-up 1m, duration 3m, error kill switch 75%, blaster aadc1a17595f) against the backfilled RPC (ledgers [64497618, 64618577], handoff wait 1426s).

Endpoint	Target RPS	Requests	Errors	p50 (ms)	p95 (ms)	p99 (ms)	p99.9 (ms)
getEvents	75	11225	4 (0.0%)	0.7	5.3	31.8	3287.0
getFeeStats	250	37493	0 (0.0%)	0.4	0.5	0.5	0.8
getHealth	250	37493	0 (0.0%)	0.4	0.5	0.5	1.0
getLatestLedger	15	2245	0 (0.0%)	2.0	5.8	8.0	22.6
getLedgers (limit=5)	3	442	0 (0.0%)	182.9	1231.9	1666.0	1813.5
getNetwork	100	14978	0 (0.0%)	0.4	0.5	0.6	3.0
getTransaction	75	11224	0 (0.0%)	5.1	11.0	18.4	25.1
getTransactions (limit=200)	10	1475	0 (0.0%)	30.5	349.7	431.4	548.4
getVersionInfo	100	14240	0 (0.0%)	0.4	0.5	0.6	2.3

getEvents results extended

Endpoint	Target RPS	Requests	Errors	p50 (ms)	p95 (ms)	p99 (ms)	p99.9 (ms)
getEvents/catch-up	3	453	0 (0.0%)	4.0	17.3	29.5	57.2
getEvents/deep-pager	17.25	2546	0 (0.0%)	0.6	21.8	86.5	1285.1
getEvents/deep-scan	2.25	345	2 (0.6%)	0.6	2.7	9.0	10002.4
getEvents/firehose	1.5	160	0 (0.0%)	0.6	2.3	2.5	3.9
getEvents/head-poll	36	5448	0 (0.0%)	0.7	4.0	6.8	42.3
getEvents/tail-poll	9	1385	2 (0.1%)	0.6	0.8	610.3	10002.4
getEvents/transfer-watcher	6	888	0 (0.0%)	3.7	5.8	6.6	7.9

Performance Evaluation Test #9

🧪 Performance Evaluation Test #9

Commit: e02b5a6f047f (cache-getLatestLedger)
Run: https://github.com/stellar/stellar-rpc/actions/runs/36019452827

✅ Backfill ingestion — verdict: ok

⏳ Backfill ingestion — `e02b5a6f047f`

Metric	Value
Ledgers ingested	120960 (`[64476288 -> 64597247]`)
Retention window	120960
Wall-clock (total)	2h48m13s
Ingest phase	2h19m0s
Bulk-load finalize phase	29m13s
Ledgers/sec (ingest)	14.5

✅ Endpoint load test — verdict: ok

🎯 Endpoint load test — `e02b5a6f047f`

Serial blast per endpoint (ramp-up 1m, duration 3m, error kill switch 75%, blaster aadc1a17595f) against the backfilled RPC (ledgers [64477042, 64598001], handoff wait 1411s).

Endpoint	Target RPS	Requests	Errors	p50 (ms)	p95 (ms)	p99 (ms)	p99.9 (ms)
getEvents	75	11224	9 (0.1%)	0.7	17.2	40.4	7004.2
getFeeStats	250	37493	0 (0.0%)	0.5	0.5	0.6	1.0
getHealth	250	37493	0 (0.0%)	0.4	0.5	0.6	1.1
getLatestLedger	15	2244	0 (0.0%)	6.2	9.9	21.3	33.2
getLedgers (limit=5)	3	442	0 (0.0%)	182.4	1151.0	1463.3	1772.5
getNetwork	100	14978	0 (0.0%)	0.4	0.5	0.6	2.3
getTransaction	75	11225	0 (0.0%)	5.2	11.6	19.1	26.0
getTransactions (limit=200)	10	1475	0 (0.0%)	26.6	316.4	368.9	492.8
getVersionInfo	100	14918	0 (0.0%)	0.4	0.5	0.6	2.7

getEvents results extended

Endpoint	Target RPS	Requests	Errors	p50 (ms)	p95 (ms)	p99 (ms)	p99.9 (ms)
getEvents/catch-up	3	440	0 (0.0%)	4.7	27.6	67.3	86.5
getEvents/deep-pager	17.25	2565	1 (0.0%)	0.7	28.2	151.8	2848.8
getEvents/deep-scan	2.25	348	4 (1.1%)	0.6	7.3	10002.4	10002.4
getEvents/firehose	1.5	202	0 (0.0%)	0.7	2.5	3.6	3.7
getEvents/head-poll	36	5403	0 (0.0%)	0.7	8.1	12.2	75.5
getEvents/tail-poll	9	1354	4 (0.3%)	0.7	0.9	7.7	10002.4
getEvents/transfer-watcher	6	912	0 (0.0%)	13.8	23.5	29.2	31.3

Performance Evaluation Test #8

🧪 Performance Evaluation Test #8

Commit: a94ef01c6640 (cache-getLatestLedger)
Run: https://github.com/stellar/stellar-rpc/actions/runs/35904387638

✅ Backfill ingestion — verdict: ok

⏳ Backfill ingestion — `a94ef01c6640`

Metric	Value
Ledgers ingested	120960 (`[64461376 -> 64582335]`)
Retention window	120960
Wall-clock (total)	2h52m59s
Ingest phase	2h23m2s
Bulk-load finalize phase	29m56s
Ledgers/sec (ingest)	14.1

✅ Endpoint load test — verdict: ok

🎯 Endpoint load test — `a94ef01c6640`

Serial blast per endpoint (ramp-up 1m, duration 3m, error kill switch 75%, blaster aadc1a17595f) against the backfilled RPC (ledgers [64462209, 64583168], handoff wait 1666s).

Endpoint	Target RPS	Requests	Errors	p50 (ms)	p95 (ms)	p99 (ms)	p99.9 (ms)
getEvents	75	11225	4 (0.0%)	0.7	14.3	39.4	4698.1
getFeeStats	250	37493	0 (0.0%)	0.4	0.4	0.5	0.8
getHealth	250	37492	0 (0.0%)	0.3	0.4	0.5	1.1
getLatestLedger	15	2244	0 (0.0%)	6.6	9.3	23.5	33.9
getLedgers (limit=5)	3	441	0 (0.0%)	193.2	1043.5	1596.4	1878.0
getNetwork	100	14978	0 (0.0%)	0.4	0.5	0.6	3.0
getTransaction	75	11224	0 (0.0%)	5.9	11.5	18.7	26.4
getTransactions (limit=200)	10	1475	0 (0.0%)	39.8	333.1	449.8	644.1
getVersionInfo	100	14393	0 (0.0%)	0.4	0.5	0.6	3.1

getEvents results extended

Endpoint	Target RPS	Requests	Errors	p50 (ms)	p95 (ms)	p99 (ms)	p99.9 (ms)
getEvents/catch-up	3	448	0 (0.0%)	5.7	34.8	53.9	183.7
getEvents/deep-pager	17.25	2544	0 (0.0%)	0.6	23.8	110.1	2807.8
getEvents/deep-scan	2.25	348	1 (0.3%)	0.6	7.8	16.3	10002.4
getEvents/firehose	1.5	219	0 (0.0%)	0.6	2.4	3.5	5.0
getEvents/head-poll	36	5367	0 (0.0%)	0.7	6.8	10.6	72.8
getEvents/tail-poll	9	1393	3 (0.2%)	0.6	0.9	1252.4	10002.4
getEvents/transfer-watcher	6	906	0 (0.0%)	10.7	19.0	23.3	26.8

Performance Evaluation Test #7

🧪 Performance Evaluation Test #7

Commit: 678da212121a (cache-getLatestLedger)
Run: https://github.com/stellar/stellar-rpc/actions/runs/35751980127

✅ Backfill ingestion — verdict: ok

⏳ Backfill ingestion — `678da212121a`

Metric	Value
Ledgers ingested	120960 (`[64442304 -> 64563263]`)
Retention window	120960
Wall-clock (total)	2h58m2s
Ingest phase	2h26m24s
Bulk-load finalize phase	31m38s
Ledgers/sec (ingest)	13.8

✅ Endpoint load test — verdict: ok

🎯 Endpoint load test — `678da212121a`

Serial blast per endpoint (ramp-up 1m, duration 3m, error kill switch 75%, blaster aadc1a17595f) against the backfilled RPC (ledgers [64443076, 64564035], handoff wait 1427s).

Endpoint	Target RPS	Requests	Errors	p50 (ms)	p95 (ms)	p99 (ms)	p99.9 (ms)
getEvents	75	11225	11 (0.1%)	1.0	15.1	74.0	9453.6
getFeeStats	250	37492	0 (0.0%)	0.7	0.8	67.5	133.0
getHealth	250	37492	0 (0.0%)	0.7	0.8	80.2	146.3
getLatestLedger	15	2244	0 (0.0%)	4.8	9.0	83.2	146.3
getLedgers (limit=5)	3	443	0 (0.0%)	180.1	1335.3	1815.6	1931.3
getNetwork	100	14978	0 (0.0%)	0.7	0.9	71.0	138.4
getTransaction	75	11225	0 (0.0%)	5.4	13.4	38.6	110.7
getTransactions (limit=200)	10	1475	0 (0.0%)	33.5	342.0	400.6	489.7
getVersionInfo	100	14031	0 (0.0%)	0.7	0.9	56.2	125.4

getEvents results extended

Endpoint	Target RPS	Requests	Errors	p50 (ms)	p95 (ms)	p99 (ms)	p99.9 (ms)
getEvents/catch-up	3	465	0 (0.0%)	4.9	33.2	72.6	185.1
getEvents/deep-pager	17.25	2626	2 (0.1%)	0.9	30.4	186.2	1934.3
getEvents/deep-scan	2.25	317	2 (0.6%)	0.9	6.4	25.8	10010.6
getEvents/firehose	1.5	211	0 (0.0%)	0.9	2.8	3.6	11.5
getEvents/head-poll	36	5381	0 (0.0%)	1.0	6.2	45.0	139.1
getEvents/tail-poll	9	1340	7 (0.5%)	0.9	1.2	732.2	10002.4
getEvents/transfer-watcher	6	885	0 (0.0%)	10.5	18.7	22.5	72.2

Performance Evaluation Test #6

🧪 Performance Evaluation Test #6

Commit: d00c2414130d (cache-getLatestLedger)
Run: https://github.com/stellar/stellar-rpc/actions/runs/35665188044

✅ Backfill ingestion — verdict: ok

⏳ Backfill ingestion — `d00c2414130d`

Metric	Value
Ledgers ingested	120960 (`[64429952 -> 64550911]`)
Retention window	120960
Wall-clock (total)	3h3m44s
Ingest phase	2h31m21s
Bulk-load finalize phase	32m23s
Ledgers/sec (ingest)	13.3

❌ Endpoint load test — verdict: fail

❌ Endpoint load test failed (run 35665188044-1 on d00c2414130dcbafb094798a58518ce3f266d22c)

target RPC http://172.31.14.196:8000: http://172.31.14.196:8000 never reported healthy (last: [-32603] Post "http://172.31.14.196:8000": dial tcp 172.31.14.196:8000: connect: no route to host): context deadline exceeded

Shaptic · 2026-09-11T22:52:14Z

+}
+
+func (c *latestLedgerCache) handle(ctx context.Context, _ protocol.GetLatestLedgerRequest) (json.RawMessage, error) {
+	latestSequence, err := c.ledgerReader.GetLatestLedgerSequence(ctx)


Instead of adding an additional complex caching layer which in turn is relying on an existing caching layer (GetLatestLedgerSequence uses the ledger range cache), we should consider extending the latter layer, instead. Namely, we could do something like extend store.LedgerRange's LedgerInfo:

// LedgerInfo identifies one ledger: its sequence number and close time. type LedgerInfo struct { Sequence uint32 CloseTime int64 + Response json.Message // can be nil }

where Response gets filled by getLedgerRangeWithCache where you can selectively decide whether substr(meta, 1, %d) AS meta_prefix is included in the DB query or if the entire meta gets returned. That way the default stays as-is, where you get faster lookups if you don't care about the entire cached meta value, but in the opt-in case, we cache the meta into LedgerInfo and propagate Response directly to the JSON marshaller.

Pros: one cache mechanism as a source of truth, DRY.
Cons: violation of abstraction barriers since the DB caching layer now speaks method JSON; the optimization propagates through the entire stack

The con can be alleviated somewhat by caching only the meta rather than the entire GetLatestLedgerResponse and computing the other fields on the fly, but then it's not as good of an optimization. But in either case, we remove the entire hairy secondary caching layer.

What do you think?

Hmm, it's a good question, and I'm not certain I have an off-the-cuff answer.

My first instinct got a bit ahead of myself -- I was hoping that the jrpc2 Bridge bypass would have covered enough slack to justify throwing out the caching optimization. Ran a quick, non-benchmark A/B test locally and discovered that is sadly not the case:

getLatestLedger (through dispatcher) Per request Allocated

Uncached, render per request 3.8 ms 15.6 MB

Cached RawMessage memo (what is committed) 0.34 ms 13 KB

Thus it doesn't seem I can dodge your question here. Also, I checked only quickly, but that speedup above is dominated by skipping the rendering -- saving only the raw fields doesn't help us much.

I like the idea of DRYing this, though I do see the con about this violating our abstraction layers. And more than that, this adds a struct that's only used by getLatestLedger rides along on a struct that shows up in getHealth, getLedgers, getTransactions, and getEvents.

I had a hard time finding a middle ground here. To me, the alteration my Claude came up with seems like perhaps a marginal improvement, but largely in the spirit of the original optimization:

Pull it out as a ~20-line generic in methods, ledgerMemo[T], keyed by sequence: load, compare, render on miss, store with a compare-and-swap that keeps the higher sequence. That covers the older-read-view case in one line. The only remaining design choice is the miss mutex: keep it if you want one render per ledger boundary under load, drop it if 3.8 ms times a few concurrent misses every five seconds is acceptable. Either way it is a self-contained, backend-agnostic piece with a two-line contract, and the store's range cache stays what it is today, a cache of scalars with its own trim and reset rules that the memo never touches.

I think I've always found memoization to be particularly tricky, and it may just be a bit late in the evening for me to try to reason about improvements to a memoization design. That is to say, I don't have strong feelings about which potential design is best here. Either way, happy to hear your thoughts!

socket-security · 2026-09-16T04:38:25Z

No dependency changes detected. Learn more about Socket for GitHub.

👍 No dependency changes detected in pull request

cjonas9 force-pushed the cache-getLatestLedger branch from 964464c to 4096f19 Compare September 11, 2026 17:40

cjonas9 added this pull request to stack #963 September 11, 2026 17:46

cjonas9 force-pushed the cache-getLatestLedger branch from 4096f19 to 8189d50 Compare September 11, 2026 20:07

cjonas9 force-pushed the cache-getLatestLedger branch from 8189d50 to 359f0db Compare September 11, 2026 20:09

cjonas9 force-pushed the cache-getLatestLedger branch from 359f0db to 827c75b Compare September 11, 2026 22:11

Shaptic reviewed Sep 11, 2026

View reviewed changes

cjonas9 force-pushed the cache-getLatestLedger branch from 827c75b to a913174 Compare September 14, 2026 15:49

cjonas9 force-pushed the cache-getLatestLedger branch from a913174 to 48486ad Compare September 14, 2026 17:03

cjonas9 force-pushed the cache-getLatestLedger branch from 48486ad to b26f427 Compare September 14, 2026 17:46

cjonas9 force-pushed the cache-getLatestLedger branch 2 times, most recently from 6d6f8df to b162128 Compare September 14, 2026 22:44

cjonas9 force-pushed the cache-getLatestLedger branch from b162128 to 8726da5 Compare September 15, 2026 21:01

cjonas9 mentioned this pull request Sep 16, 2026

jhttp: serve POSTs directly, pass json.RawMessage results through stellar-experimental/jrpc2#1

Open

cjonas9 force-pushed the cache-getLatestLedger branch from 8726da5 to 644b17d Compare September 16, 2026 04:37

cjonas9 force-pushed the cache-getLatestLedger branch from 1f06ef3 to 7168be4 Compare September 17, 2026 22:10

cjonas9 removed this pull request from stack #963 September 18, 2026 20:16

cjonas9 changed the title ~~[DRAFT] optimize getLatestLedger: cache and bypass jrpc2 marshal + unmarshal~~ [DRAFT] Optimize query-path caching and bypass jrpc2 marshal + unmarshal Sep 21, 2026

cjonas9 force-pushed the cache-getLatestLedger branch from a94ef01 to e02b5a6 Compare September 24, 2026 15:20

cjonas9 removed this pull request from stack #1031 September 24, 2026 15:24

cjonas9 changed the base branch from scanledgers-iterator to bypass-jrpc2-marshal September 24, 2026 15:24

cjonas9 added this pull request to stack #1038 September 24, 2026 15:24

cjonas9 changed the title ~~[DRAFT] Optimize query-path caching and bypass jrpc2 marshal + unmarshal~~ [DRAFT] Optimize query-path caching/memoization Sep 24, 2026

cjonas9 mentioned this pull request Sep 25, 2026

Use views in getProtocolVersion #1035

Merged

cjonas9 force-pushed the cache-getLatestLedger branch from e02b5a6 to 36b32d0 Compare September 25, 2026 17:59

cjonas9 mentioned this pull request Sep 25, 2026

Commit ingestion transactions outside the ledger-range cache lock #1036

Merged

cjonas9 force-pushed the cache-getLatestLedger branch 2 times, most recently from 0b71b38 to 190e08d Compare September 25, 2026 20:03

cjonas9 added rpc-sdk-scrum performance-pod-scrum labels Sep 29, 2026

cjonas9 added this to Platform Scrum Sep 29, 2026

github-project-automation Bot moved this to To Do in Platform Scrum Sep 29, 2026

cjonas9 added this to the platform sprint 76 milestone Sep 29, 2026

This was referenced Sep 30, 2026

Cache/memoize per-ledger work in the endpoint handlers for performance #989

Open

Raw response passthrough: stop jrpc2 from re-marshaling and re-parsing handler results #1056

Open

cjonas9 force-pushed the cache-getLatestLedger branch from 190e08d to 7af387a Compare September 30, 2026 20:24

cjonas9 closed this Oct 2, 2026

cjonas9 force-pushed the cache-getLatestLedger branch from 7af387a to 8d09af8 Compare October 2, 2026 23:22

cjonas9 merged commit 8d09af8 into feature/full-history Oct 2, 2026

github-project-automation Bot moved this from In Progress to Done in Platform Scrum Oct 2, 2026

cjonas9 deleted the cache-getLatestLedger branch October 2, 2026 23:22

cjonas9 restored the cache-getLatestLedger branch October 2, 2026 23:28

This was referenced Oct 2, 2026

[DRAFT] Optimize query-path caching/memoization #1060

Draft

Bypass jrpc2 marshal to enable raw endpoint response passthrough #1037

Open

getLatestLedger (through dispatcher)	Per request	Allocated
Uncached, render per request	3.8 ms	15.6 MB
Cached RawMessage memo (what is committed)	0.34 ms	13 KB

Conversation

cjonas9 commented Sep 11, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What

Measurements

Tests

Why

Known limitations / additional notes

Uh oh!

github-actions Bot commented Sep 11, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

🧪 Performance Evaluation Test #11

✅ Backfill ingestion — verdict: ok

⏳ Backfill ingestion — 7af387ac1ed6

✅ Endpoint load test — verdict: ok

🎯 Endpoint load test — 7af387ac1ed6

🧪 Performance Evaluation Test #10

✅ Backfill ingestion — verdict: ok

⏳ Backfill ingestion — 190e08d28bb5

✅ Endpoint load test — verdict: ok

🎯 Endpoint load test — 190e08d28bb5

🧪 Performance Evaluation Test #9

✅ Backfill ingestion — verdict: ok

⏳ Backfill ingestion — e02b5a6f047f

✅ Endpoint load test — verdict: ok

🎯 Endpoint load test — e02b5a6f047f

🧪 Performance Evaluation Test #8

✅ Backfill ingestion — verdict: ok

⏳ Backfill ingestion — a94ef01c6640

✅ Endpoint load test — verdict: ok

🎯 Endpoint load test — a94ef01c6640

🧪 Performance Evaluation Test #7

✅ Backfill ingestion — verdict: ok

⏳ Backfill ingestion — 678da212121a

✅ Endpoint load test — verdict: ok

🎯 Endpoint load test — 678da212121a

🧪 Performance Evaluation Test #6

✅ Backfill ingestion — verdict: ok

⏳ Backfill ingestion — d00c2414130d

❌ Endpoint load test — verdict: fail

Uh oh!

Shaptic Sep 11, 2026

Choose a reason for hiding this comment

Uh oh!

cjonas9 Sep 12, 2026

Choose a reason for hiding this comment

Uh oh!

socket-security Bot commented Sep 16, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

cjonas9 commented Sep 11, 2026 •

edited

Loading

github-actions Bot commented Sep 11, 2026 •

edited

Loading

⏳ Backfill ingestion — `7af387ac1ed6`

🎯 Endpoint load test — `7af387ac1ed6`

⏳ Backfill ingestion — `190e08d28bb5`

🎯 Endpoint load test — `190e08d28bb5`

⏳ Backfill ingestion — `e02b5a6f047f`

🎯 Endpoint load test — `e02b5a6f047f`

⏳ Backfill ingestion — `a94ef01c6640`

🎯 Endpoint load test — `a94ef01c6640`

⏳ Backfill ingestion — `678da212121a`

🎯 Endpoint load test — `678da212121a`

⏳ Backfill ingestion — `d00c2414130d`

socket-security Bot commented Sep 16, 2026 •

edited

Loading