Cyper-axum huge performance degradation with Keep-Alive (HTTP 1?) connections

[inklesspen1rus]

Issue

I benchmarked axum+tokio(current thread flavor) and cyper-axum+compio with and without Keep-Alive.
The server is simple: return 64KiB of data (result verified by response document length).
For some reason, Keep-Alive connections causes HUGE RPS drop.

Expected behavior

For any server for any case etc... Keep-Alive should improve performance due to connection caching.

Actual behavior

Dealing with keep-alive connections causes 100X RPS drop.
While axum+tokio has 3X improvement

My benchmark results

Example	Keep-Alive	RPS	Command	Benchmark command
axum+tokio	No	16515.13	cargo run --release --bin server-tokio	ab -c 4 -t 5 -n 100000 http://127.0.0.1:3000/
axum+tokio	Yes	51462.06	cargo run --release --bin server-tokio	ab -k -c 4 -t 5 -n 100000 http://127.0.0.1:3000/
cyper-axum+compio	No	9789.98	cargo run --release --bin server-cyper	ab -c 4 -t 5 -n 100000 http://127.0.0.1:3000/
cyper-axum+compio	Yes	98.27	cargo run --release --bin server-cyper	ab -k -c 4 -t 5 -n 100000 http://127.0.0.1:3000/

Steps to reproduce

• Clone repository: https://github.com/inklesspen1rus/cyper-axum-issue
• Run server using command from benchmark results (for axum+tokio: cargo run --release --bin server-tokio )
• Run benchmark command from benchmark results (for Keep-Alive=Yes: ab -k -c 4 -t 5 -n 100000 http://127.0.0.1:3000/)

Environment

rustc 1.90.0-nightly (706f244db 2025-06-23)
cargo 1.90.0-nightly (84709f085 2025-06-22)
nightly-x86_64-unknown-linux-gnu

OS: Manjaro Linux x86_64 
Host: B550 AORUS ELITE V2 
Kernel: 6.15.8-1-MANJARO 
Uptime: 5 hours, 28 mins 
Packages: 2010 (pacman), 29 (flatpak), 11 (snap) 
Shell: bash 5.3.3 
Resolution: 1920x1080 
DE: Plasma 6.4.3 
WM: kwin 
Theme: Breath Dark [Plasma], Breeze-Dark [GTK2], Breeze [GTK3] 
Icons: breeze [Plasma], breeze [GTK2/3] 
Terminal: vscode 
CPU: AMD Ryzen 5 5600 (12) @ 4.470GHz 
GPU: NVIDIA GeForce GTX 1060 6GB 
Memory: 19931MiB / 32010MiB

[umbrageodotus]

It COULD be fixed by my PR, as an error in the connection could lead to a 1s wait, about consistent with the RPS drop you've mentioned.

[Berrysoft]

It COULD be fixed by my PR, as an error in the connection could lead to a 1s wait, about consistent with the RPS drop you've mentioned.

The code is ported from axum. https://github.com/tokio-rs/axum/blob/37a08a17d40690ece6c4c9d9ada9aaf4e5c33296/axum/src/serve/listener.rs#L245-L263