imbajin commented on issue #3346: URL: https://github.com/apache/hugegraph/issues/3346#issuecomment-6218173541
### Server HTTP performance: Jersey/Grizzly versions, concurrency and response memory Add a **Server-specific** investigation here, covering high concurrent request load and individual requests that consume substantial CPU or memory. PD/Store's Spring Boot applications and their framework migration are separate work. Keep backend versions and deployment settings fixed when measuring Server overhead. **Current observations** - Server declares [Jersey 3.0.3](https://github.com/apache/hugegraph/blob/6f98193eac966421e499f5d506d86b22094b52cd/hugegraph-server/pom.xml#L49) and explicitly pins [Grizzly 3.0.1](https://github.com/apache/hugegraph/blob/6f98193eac966421e499f5d506d86b22094b52cd/hugegraph-server/hugegraph-api/pom.xml#L125-L144). Treat Jersey version and HTTP container choice as separate performance variables. - [JsonSerializer.writeIterator()](https://github.com/apache/hugegraph/blob/6f98193eac966421e499f5d506d86b22094b52cd/hugegraph-server/hugegraph-api/src/main/java/org/apache/hugegraph/serializer/JsonSerializer.java#L104-L152) sequentially consumes results, serializes each item into temporary strings/bytes, accumulates a complete byte buffer, then returns a complete response String. This path merits allocation and peak-memory measurements for large results; replacing the container alone will retain this application-level materialization. - [RestServer](https://github.com/apache/hugegraph/blob/6f98193eac966421e499f5d506d86b22094b52cd/hugegraph-server/hugegraph-api/src/main/java/org/apache/hugegraph/server/RestServer.java#L99-L111) configures a fixed worker pool, defaulting to 2 x CPU, without explicitly bounding its task queue. The Jersey load filter is not a complete admission limit before worker dispatch. Measure queue growth, saturation and response-write retention rather than assuming the request counter covers all outstanding work. - REST `/gremlin` synchronously forwards to a separate TinkerPop/Netty service. Measure graph REST, proxied Gremlin and direct Gremlin independently to distinguish REST overhead, connection-pool waits and query execution. These are code observations and investigation candidates, **not confirmed causes of a production incident**. No new HugeGraph runtime benchmark has been run for this note. **Public measurements worth retaining** - [TechEmpower Round 23](https://www.techempower.com/benchmarks/#section=data-r23&test=json), [raw data](https://www.techempower.com/benchmarks/results/round23/ph.json): at JSON concurrency 512, approximately 1.99M req/s for bare Grizzly, 1.27M for bare Jetty and 0.563M for Grizzly/Jersey. However, the Jersey entry uses **Jersey 2.28 / Grizzly 2.4.4 / JDK 11**, with substantial [configuration changes](https://github.com/TechEmpower/FrameworkBenchmarks/blob/R23/frameworks/Java/grizzly/src-jersey/main/java/hello/WebServer.java), including disabling the worker pool. Different implementations and tiny responses prevent attributing the whole gap to Jersey or predicting HugeGraph gains. - [Jersey maintainer's 3.1.0 -> 3.1.1 measurements](https://blog.supol.cz/?p=301), JDK 11: short JSON GET/POST throughput improved about 9%/25%, while 40,000-character JSON GET/POST improved about 3%/1%. Results are path-dependent; the article does not provide a complete reproducible environment, and some changes affect both client and server. Its Client/WebTarget reuse figures are not Server upgrade results. - A [same-Jersey container comparison](https://abobos.com/2016/03/12/java-rest-api-benchmark-tomcat-vs-jetty-vs-grizzly-vs-undertow-round-3/) found Grizzly competitive, but dates from 2016/Java 8. It cannot settle current container selection. We have not found a reliable, controlled Jersey 3.0.3 / 3.1.x / 4.x comparison covering large responses, slow clients and memory. Active maintenance or a larger version number does not establish performance acceptance. **Focused benchmark TODO** - [ ] Compare the current stack with newer Jersey/compatible Grizzly versions; separately compare Grizzly and Jetty using the same Jersey resources. Fix JDK, JSON provider, heap, CPU allocation and worker budgets, and record unavoidable compatibility changes. - [ ] Cover small responses, point queries, representative traversals, large results, slow clients, single expensive requests and mixed concurrent traffic. Preserve result correctness and API behavior. - [ ] Capture sustained throughput, p95/p99, errors/rejections, queueing, CPU profiles, allocation/request, peak heap, retained objects and GC. Separate query computation, serialization and network waits; a hot single thread alone does not identify the container as the bottleneck. - [ ] Evaluate response materialization and admission/queue limits as separate candidates, with before/after measurements. Implement only changes justified by the results; no framework replacement is selected by this comment. - [ ] Run heavier baselines as dedicated manual or scheduled performance jobs, not on every ordinary PR push. Add lightweight regression checks only after a reproducible issue and useful acceptance criteria exist. -- 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
