therealaleph
4c8cf9ac16
Bumps Cargo.toml v1.9.20 → v1.9.21 and ships the changelog. Headline: PR #1040 (@yyoyoian-pixel) skips H2 multiplexing for tunnel_batch_request_to (Full-mode batch path). Tunnel batches already coalesce N ops into one HTTP request, so H2 stream multiplexing has nothing to multiplex there; the H2 path was actively hurting via long-poll stalls + silent batch drops + pool starvation. H2 remains active for relay mode (apps_script), where r0ar's #962 A/B data confirmed it's strictly better. A/B on Pixel 6 Pro: 0/30 vs 8-10/30 long-poll stalls. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
3.5 KiB
• Perf: skip H2 برای Full-tunnel batch requests (PR #1040 by @yyoyoian-pixel). Full mode tunnel batches قبلاً N op رو در یک HTTP request coalesce میکنند — H2 stream multiplexing چیزی برای multiplex کردن نداره. H2 try/fallback path در این مسیر خاص سه regression از v1.9.14 معرفی کرد: (1) long-poll stallها در ۱۶-۱۷s به جای 10s timeout روی H1 — هر poll ~۶۰٪ بیشتر slot Apps Script رو نگه میداشت، (2) silent batch drops via `RequestSent::Maybe` بدون retry، (3) pool starvation از `POOL_MIN_H2_FALLBACK = 2` که از 8 → 2 trim میکرد. H2 multiplexing برای relay mode (apps_script) فعال میمونه — اونجا واقعاً بهدرد میخوره (r0ar در #962 confirmed). A/B روی Pixel 6 Pro: 0/30 vs 8-10/30 long-poll stalls. ۲۰۹ lib test still pass. v1.9.14 tunnel performance بازگشت + همه v1.9.15+ improvements حفظ شد (relay mode h2، zero-copy mux، block DoH/QUIC، PR #1029 warm-race fix).
• Perf: skip H2 for Full-tunnel batch requests (PR #1040 by @yyoyoian-pixel). Tunnel batches already coalesce N ops into one HTTP request — H2 stream multiplexing has nothing to multiplex on this code path. The H2 try/fallback block introduced three regressions vs v1.9.14:
- Long-poll stalls: idle polls completed at 16-17s (
LONGPOLL_DEADLINE+ network latency) instead of timing out at 10s on H1. Each poll held an Apps Script execution slot ~60% longer. - Silent batch drops:
RequestSent::Maybefailures dropped the entire batch with no retry — a failure mode H1 doesn't have. - Pool starvation:
POOL_MIN_H2_FALLBACK = 2trimmed the H1 pool from 8 → 2 once H2 connected, but tunnel batches still used H1 and needed the full pool.
H2 multiplexing stays active for relay mode (non-full) where each browser request is a separate HTTP call that genuinely benefits from stream multiplexing — r0ar's controlled A/B test in #962 confirmed h2 is strictly better than force_http1: true for apps_script-mode users, and that path is unchanged here.
Changes (domain_fronter.rs-only, -54/-12 lines, +12 net)
tunnel_batch_request_to: remove H2 try/fallback/NonRetryable block, go straight to H1 poolacquire().run_pool_refill: always maintainPOOL_MIN = 8. Remove thePOOL_MIN_H2_FALLBACK = 2trim.
A/B results (Pixel 6 Pro, 30 batch samples each)
| Metric | H2 (stock v1.9.20) | H1 (this release) | v1.9.14 (baseline) |
|---|---|---|---|
| 16-17s batches | 8-10/30 | 0/30 | 0/30 |
| 10s timeouts | 0 | 4/30 | 5/30 |
| Active RTTs | 1.4-2.4s | 1.3-2.2s | 1.4-2.3s |
Restores v1.9.14 tunnel performance while keeping all v1.9.15+ improvements (H2 for relay, zero-copy mux from PR #881, block DoH/QUIC defaults from v1.9.13/14, PR #1029's warm-race fix from v1.9.20).
Interaction with v1.9.20 (PR #1029)
PR #1029 added H2Cell.dead: Arc<AtomicBool> for synchronous dead-cell detection. With this release removing the H2 path for tunnel batches, the dead-cell flag scopes to relay mode only — that's intentional (the flag was protecting the relay path in practice). No regression.
209 lib tests still pass (no test changes — the affected paths are exercised by integration probes which the PR reporter ran on Pixel 6 Pro).