HomeBlogPricingCareersDocsGitHubSlack community
Field notes/Community builds/Where Sandbox Ingress Speed Actually Comes From

Where Sandbox Ingress Speed Actually Comes From

A staged reading of the ingress rebuild: dropping the L7 parser did most of the work, and kTLS added the smaller remainder.

SBX-01C4SBX-01E3SBX-0202SBX-0221SBX-0240SBX-025FSBX-027ESBX-029DSBX-02BCSBX-02DBSBX-02FASBX-0319SBX-0338SBX-0357SBX-0376[ RUNTIME: ACTIVE ] P50 2.45S · P99 4.12S · 5M/PROJECT

Divy takes our sandbox networking post apart and asks which change actually caused the speedup. The staged numbers answer it: moving the dataplane hop from an L7 proxy to a plain L4 forwarder went from 1.12 to 2.07 GB/s and cut CPU from 0.90 to 0.50 CPU-seconds per GB, then kTLS and splice(2) added 0.43 GB/s on top and almost no CPU. We expected kTLS to be the win, so this is the more useful read: removing the parser was. The rest of the piece is the part a reader can reuse, on what an L7 hop buys you, what has to be rebuilt when it goes away (routing moves into a preamble, liveness becomes metered bytes), and why a workload of short lifecycle calls should expect nothing from any of it.

We didn’t write this one — it’s Divy Yadav’s piece, published on Towards AI. The note above is ours; the full article is theirs.

Read the full piece on Towards AI
DY
WRITTEN BYDivy YadavCommunity · Towards AI
Read next —FROM THE LOG
◆ THE SANDBOX DIGEST

Subscribe for release notes, benchmarks, deep dives.

One dispatch per month from the Tensorlake team — no spam.