http-over-polling

http-over-polling

A net/http-compatible HTTP stack on top of cloudwego/netpoll.

If you want to keep normal handlers and framework code, but cut idle-connection goroutine growth and explore poller-driven WebSocket handling, this repo is built to show that with runnable examples and repeatable benchmarks.

Platform note: the core transport path and bundled examples are currently intended for Linux and macOS. Windows is not a supported target at this time.

Why it stands out

At a glance

Idle and WebSocket goroutine profile

Measured by examples/integration/wsdemo_bench_test.go at 4096 concurrent connections.

What this means in practice:

Run it yourself:

cd examples
go test ./integration -run '^$' -bench WebSocketServerGoroutines -benchmem -benchtime=1x -count=1

Increase the benchmark connection count:

cd examples
WSDEMO_CONN_COUNT=128 go test ./integration -run '^$' -bench WebSocketServerGoroutines -benchmem -count=1

wrk result on the bundled example workload

Result source: examples/.wrk-results/20260314-200547/

Command shape:

wrk -t6 -c300 -d30s http://localhost:8080

Headline takeaway:

This is intentionally scoped evidence, not a blanket claim about every production workload.

What you can run

Example servers

Run them:

cd examples && go run ./cmd/stdhttp_example
cd examples && go run ./cmd/netpoll_example
cd examples && go run ./cmd/ws_example

WebSocket example endpoints

The point is not just that WebSockets work. The point is that you can see which styles keep the poller model and which styles fall back to legacy goroutine-heavy behavior.

Framework compatibility

If you already use a normal net/http framework, the pitch is simple: keep your handler code, change the server path.

Run the compatibility tests:

cd examples
go test ./integration -run 'TestChiCompatibility|TestGinCompatibility|TestEchoCompatibility' -count=1

In-memory benches are included too

This repo is not only about process-level demos.

These are useful for different questions:

Public API

The main public entrypoint stays small:

err := hop.ListenAndServe(":8080", handler)

Request path:

1. transport.ListenAndServe(...)
2. transport.Events
3. hop.NewHttpConn(...)
4. internal/parser request parsing
5. http.Handler execution

Core layout

Command index

Go commands

wrk commands

Reproducing the headline result

If you want the same style of numbers shown above, use built binaries and the bundled script:

cd examples
./scripts/wrk_compare.sh

If you want manual runs instead:

cd examples && go run ./cmd/stdhttp_example
wrk -t6 -c300 -d30s http://localhost:8080

cd examples && go run ./cmd/netpoll_example
wrk -t6 -c300 -d30s http://localhost:8080

If you specifically want latency percentiles as a separate measurement pass:

cd examples
WITH_LATENCY=1 ./scripts/wrk_compare.sh

Honest scope

This project is strongest when described this way:

• it shows a real goroutine-usage difference between legacy and poller-driven connection handling
• it ships a local wrk workload where the hop path can outperform the stdlib baseline
• it proves compatibility with existing net/http frameworks
• it gives you enough examples and benches to rerun the claims yourself

That is more persuasive than a generic "faster than net/http" slogan, because the evidence is shipped with the code.

Acknowledgements

This project references and learns from the ideas and implementations in:

• https://github.com/valyala/bytebufferpool
• https://github.com/valyala/fasthttp/tree/master/tcplisten

Thanks to the authors and maintainers of those projects.