Skip to content

Commit f01387c

Browse files
committed
docs(readme): Document performance envelope and HttpServer caveats
Captures the curl/k6 measurements (20k–35k rps on a dev laptop, 0% HTTP failures) and flags the known JDK HttpServer keep-alive edge case that causes some clients to see empty response bodies under aggressive connection reuse. Also notes the -1 vs 0 sendResponseHeaders gotcha.
1 parent f7a8f11 commit f01387c

1 file changed

Lines changed: 13 additions & 0 deletions

File tree

README.md

Lines changed: 13 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -120,4 +120,17 @@ Schemas are located under test resources folder.
120120
- Example requests can be found under `acceptance/k6` that can be a base for exploring the functionality.
121121
- The logger in the configuration needs to be enabled to get some insight into the code.
122122

123+
## Performance and caveats
124+
125+
The library wraps the JDK's bundled `com.sun.net.httpserver.HttpServer` and uses a virtual-thread-per-request executor. On a developer laptop (Apple Silicon, single instance, default JVM flags) it sustains roughly:
126+
127+
- **20k–35k requests/second** for small JSON GETs and POSTs (~300 byte bodies), measured both via parallelised `curl` (no connection reuse) and via `k6` at moderate VU counts.
128+
- The HTTP layer reports **0% request failures** even when sustained at 30 concurrent virtual users for 45 seconds (~1.5M requests).
129+
130+
That said, the underlying JDK HttpServer is documented as a low-throughput / dev-test server, and a few caveats are worth knowing:
131+
132+
- **Keep-alive reuse at high concurrency.** k6 and other clients that aggressively reuse HTTP/1.1 connections will occasionally observe empty response bodies (with the correct `Content-Length` header) when running tens of VUs against this server. Curl-style clients that open a fresh connection per request do not see this. If you need consistent throughput above a few thousand RPS with keep-alive clients, consider deploying behind a real HTTP server (Jetty, Helidon Níma, Netty) — this library's filter/validator stack is independent of the underlying server and could be ported.
133+
- **Single-process model.** No horizontal scaling primitives are bundled; run multiple instances behind a load balancer for production scale.
134+
- **`HttpExchange.sendResponseHeaders(rCode, length)` semantics.** When a handler has no response body, pass `-1` (no body, `Content-Length: 0`); passing `0` produces a chunked response with zero chunks, which is technically non-conformant.
135+
123136
## Known limitations or missing features

0 commit comments

Comments
 (0)