Files
therealaleph b030aaf454 v1.6.4: fix Full-mode L7 muxer not batching ops (#231)
The batch-build loop blocked on a 30 ms timeout for the first message,
then drained whatever else was in the channel via try_recv() and fired
the batch. Under any non-bursty workload, the channel queue was always
empty by the time the first op woke us up — so every "batch" had
exactly one op, defeating the entire batching premise. Reporter (w0l4i)
saw `batch: 1 ops → ..., rtt=6.3 s` repeating in logs even under high
concurrency.

Fix: after the first op lands, hold the buffer open for an 8 ms
coalescing window. Concurrent ops (parallel fetches, HTTP/2 stream
openings, etc.) now accumulate into the same batch. 8 ms is rounding
error against the 2–7 s Apps Script RTT we're amortizing, and restores
the multi-op-per-batch behavior the rest of the code already supports
(MAX_BATCH_OPS=50, MAX_BATCH_PAYLOAD_BYTES=4 MiB).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-26 08:34:19 +03:00

2.0 KiB

• رفع باگ "L7 multiplexer در Full mode batch نمی‌کنه" (#231): در حالت Full، انتظار می‌رفت که چند op به یک batch HTTP request به Apps Script ترکیب بشن (batch: 5 ops یا batch: 10 ops)، ولی log نشون می‌داد همیشه batch: 1 ops — یعنی هر op جدا یه round-trip Apps Script می‌گرفت (که هر کدوم 2 تا 7 ثانیه طول می‌کشن). علت: loop دریافت پیام بلافاصله بعد از اولین message با try_recv() (non-blocking) صف رو drain می‌کرد، بدون pause برای جمع‌آوری بقیه ops. Fix: بعد از اولین op، یه پنجرهٔ ۸ میلی‌ثانیه‌ای باز می‌مونه تا opهای بعدی (مثل parallel fetches، HTTP/2 streams) همون batch رو پر کنن. ۸ms در مقابل ~۲ تا ۷ ثانیه RTT Apps Script اصلاً ناچیزه ولی efficiency batching رو برمی‌گردونه. ریپورت شده توسط w0l4i با log واضح

• Fix "L7 multiplexer not batching in Full mode" bug (#231): in full mode, multiple ops should coalesce into a single batched HTTP request to Apps Script (batch: 5 ops or batch: 10 ops), but logs showed batch: 1 ops consistently — each op got its own Apps Script round-trip (2-7 s each). Cause: the receive loop drained the channel via try_recv() (non-blocking) immediately after the first message arrived, with no window to let concurrent ops accumulate. Fix: after the first op lands, hold the buffer open for an 8 ms coalescing window so concurrent ops (parallel fetches, HTTP/2 stream openings, etc.) land in the same batch. 8 ms is rounding error against the ~2-7 s Apps Script RTT but restores the entire batching premise. Reported by w0l4i with a clean log snippet