[PR #107] [MERGED] perf(p2p): parallelize catalog peer lookups #185

New issue

Closed

opened 2026-10-29 14:20:46 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-29 14:20:46 +00:00

Owner

📋 Pull Request Information

Original PR: https://github.com/kvcache-ai/AgentENV/pull/107
Author: @catyans
Created: 8/3/2026
Status: ✅ Merged
Merged: 8/25/2026
Merged by: @LSX-s-Software

Base: main ← Head: perf/p2p-parallel-catalog-lookup

📝 Commits (5)

326592f perf(p2p): parallelize catalog peer lookups
cda8d77 fix(p2p): consume buffered lookup results directly
f8603dd style(p2p): apply rustfmt to lookup helper
70ccd6d test(p2p): synchronize concurrency window assertion
951f1cb test(p2p): bound buffered lookup synchronization

📊 Changes

1 file changed (+139 additions, -12 deletions)

View changed files

📝 src/p2p/iroh/transport.rs (+139 -12)

📄 Description

Summary

run Iroh catalog lookups with a fixed four-peer concurrency window
preserve scheduler-provided candidate order when selecting a descriptor
keep misses, timeouts, invalid endpoints, and self/local candidates compatible with the existing fallback behavior
add deterministic coverage for ordering and the in-flight concurrency bound

Why

lookup_peers currently waits for every candidate serially. With the default
5-second per-peer timeout, stale peers at the front of the discovery result can
make lookup latency grow as N * lookup_timeout.

The new ordered buffer starts up to four lookups concurrently but consumes their
results in candidate order. This bounds connection fan-out and reduces timeout
accumulation without changing scheduler priority.

Lingjun validation

Validation was run on the four-node Lingjun cluster, not on the development
machine.

cargo fmt --all -- --check
new ordered-buffer tests: 2 passed
p2p::iroh::transport::tests: 14 passed

Four-node latency experiment

consumer: lingjun-099 (192.168.0.42)
stale Iroh endpoints: lingjun-100 and lingjun-101
valid provider: lingjun-102
lookup timeout: 1000 ms
candidate order: stale-100, stale-101, valid-102

All endpoints were produced by real IrohBlobsP2pTransport instances. The first
two providers were then stopped before measurement; the third continued serving
the published artifact.

implementation	five lookup samples (ms)	mean (ms)
current serial `main`	2028.327, 2029.424, 2028.062, 2026.525, 2026.695	2027.807
ordered concurrency window	1000.855, 1002.165, 1000.564, 1001.104, 1001.576	1001.253

The change reduced mean lookup latency by approximately 50.6%; all 10/10
lookups returned the descriptor from lingjun-102.

The branch was subsequently rebased onto v0.1.1 main; git range-diff
confirmed that all four patch commits remained identical.

Fixes #95

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/kvcache-ai/AgentENV/pull/107 **Author:** [@catyans](https://github.com/catyans) **Created:** 8/3/2026 **Status:** ✅ Merged **Merged:** 8/25/2026 **Merged by:** [@LSX-s-Software](https://github.com/LSX-s-Software) **Base:** `main` ← **Head:** `perf/p2p-parallel-catalog-lookup` --- ### 📝 Commits (5) - [`326592f`](https://github.com/kvcache-ai/AgentENV/commit/326592f74b09b42a78395c8e2d68ab216d0c58c8) perf(p2p): parallelize catalog peer lookups - [`cda8d77`](https://github.com/kvcache-ai/AgentENV/commit/cda8d77c6a33640aad7294075d6fc517bc1b6501) fix(p2p): consume buffered lookup results directly - [`f8603dd`](https://github.com/kvcache-ai/AgentENV/commit/f8603dd975253d590b9c2c1a23b7ee5fb9bfa4f3) style(p2p): apply rustfmt to lookup helper - [`70ccd6d`](https://github.com/kvcache-ai/AgentENV/commit/70ccd6d270f80802945cc615b58ea7c03bcb824d) test(p2p): synchronize concurrency window assertion - [`951f1cb`](https://github.com/kvcache-ai/AgentENV/commit/951f1cb27a25706abd32b73762f772f2671c6de3) test(p2p): bound buffered lookup synchronization ### 📊 Changes **1 file changed** (+139 additions, -12 deletions) <details> <summary>View changed files</summary> 📝 `src/p2p/iroh/transport.rs` (+139 -12) </details> ### 📄 Description ## Summary - run Iroh catalog lookups with a fixed four-peer concurrency window - preserve scheduler-provided candidate order when selecting a descriptor - keep misses, timeouts, invalid endpoints, and self/local candidates compatible with the existing fallback behavior - add deterministic coverage for ordering and the in-flight concurrency bound ## Why `lookup_peers` currently waits for every candidate serially. With the default 5-second per-peer timeout, stale peers at the front of the discovery result can make lookup latency grow as `N * lookup_timeout`. The new ordered buffer starts up to four lookups concurrently but consumes their results in candidate order. This bounds connection fan-out and reduces timeout accumulation without changing scheduler priority. ## Lingjun validation Validation was run on the four-node Lingjun cluster, not on the development machine. - `cargo fmt --all -- --check` - new ordered-buffer tests: 2 passed - `p2p::iroh::transport::tests`: 14 passed ### Four-node latency experiment - consumer: lingjun-099 (`192.168.0.42`) - stale Iroh endpoints: lingjun-100 and lingjun-101 - valid provider: lingjun-102 - lookup timeout: 1000 ms - candidate order: stale-100, stale-101, valid-102 All endpoints were produced by real `IrohBlobsP2pTransport` instances. The first two providers were then stopped before measurement; the third continued serving the published artifact. | implementation | five lookup samples (ms) | mean (ms) | |---|---|---:| | current serial `main` | 2028.327, 2029.424, 2028.062, 2026.525, 2026.695 | 2027.807 | | ordered concurrency window | 1000.855, 1002.165, 1000.564, 1001.104, 1001.576 | 1001.253 | The change reduced mean lookup latency by approximately 50.6%; all 10/10 lookups returned the descriptor from lingjun-102. The branch was subsequently rebased onto v0.1.1 `main`; `git range-diff` confirmed that all four patch commits remained identical. Fixes #95 --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>

bsakaguchi

2026-10-29 14:20:46 +00:00