AlinsRan commented on PR #13912: URL: https://github.com/apache/apisix/pull/13912#issuecomment-5533892492
Follow-up on P2 with the measurements you asked for — my earlier reply confirmed the topology but skipped the numbers, which is the part you actually asked for. ## Is the hop required? Yes, for a shared listener. `ssl_preread on` and `listen ... ssl` cannot coexist on one server: I measured it, the handshake completes and the preread phase then never sees a ClientHello, so the connection stalls. The terminating half therefore has to be a separate `server`, and the only way Lua can hand a connection to another server block is a socket. Kong solves the same constraint the same way. I know of no implementation without the hop, given that constraint. ## Numbers Same box, same backend, same route; one port declared `tls_passthrough` (direct) and one declared `tls` + `tls_passthrough` (mixed, passthrough branch). Backend terminates TLS itself in both cases, so the handshake cost is identical and only the hop differs. **Connection rate** (600-800 TLS connections, concurrency 8, 3 runs): mixed/direct ratio came out 1.011, 0.971, 0.871. The direct baseline itself varied from 1549 to 1921 conn/s across runs, a wider spread than the gap, so I read this as **no difference distinguishable from run-to-run variance**. **Throughput** (4 MiB responses, concurrency 4, 8 runs): mixed was lower in every run — ratios 0.979, 0.857, 0.825, 0.852, 0.666, 0.783, 0.661, 0.833, median ≈ 0.78. So roughly **15-35% lower throughput**, consistent with one extra copy per byte through the unix socket. Caveats I would rather state than paper over: this is a shared, noisy machine, the spread is wide, and I did not measure memory or CPU attribution — only connection rate and throughput. Treat the throughput figure as indicative of the direction and rough magnitude, not as a benchmark result. ## Assessment Keep the trade-off, but keep it opt-in, which is what the current shape does: - mixed is reached only when both flags are set on one listen; it is never a default and never an upgrade of an existing port; - dedicated `tls` and `tls_passthrough` listens keep the direct path and are unaffected — verified from the rendered config, they `proxy_pass apisix_backend` directly; - the cost lands on bulk transfer, which is exactly the workload that should use a dedicated port, and the docs already recommend a dedicated `tls_passthrough` port whenever a whole port passes through. That said, mixed mode is not what this PR is really for. The Gateway API core `TLSRoute` feature is passthrough, and a dedicated passthrough listen serves it with no hop at all. **If you would prefer, I will drop mixed mode from this PR** and ship the two direct modes only, proposing the shared-listener case separately with these numbers attached. Say which you prefer and I will push it. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
