Aias00 opened a new issue, #7650: URL: https://github.com/apache/shenyu/issues/7650
## Goal Establish a reproducible performance baseline and coordinate small, independently validated optimizations for request CPU cost, connection/memory capacity and configuration-update disturbance. Reviewed source baseline: `apache/shenyu@b4e115367fd57adc8aba332d655b1009932ba394`. No performance load test was run during issue preparation; candidates are source-grounded hypotheses, not measured bottlenecks or promised improvement percentages. ## First deliverable: benchmark contract Use an existing compatible load generator with fixed arrival-rate support and JFR profiling; do not add benchmark/runtime dependencies without a demonstrated need. Keep the benchmark harness outside the default production runtime. Record gateway/upstream commits, JDK, CPU quota, heap/direct-memory limits, plugin/configuration set, generator placement and upstream behavior. | Workload | Variables | Evidence to collect | | --- | --- | --- | | HTTP proxy | concurrency/rate, small/large responses, controlled slow upstreams, HTTP/TLS and reuse | successful throughput, p50/p95/p99, errors, CPU, active/new/pending connections | | Matching | 100/1k/10k configs; exact/prefix/regex/pathPattern and mixed header/query conditions; cache on/off | match cost, cache hit rate, allocation and CPU profile, result equivalence | | Sync under traffic | initial snapshot, incremental changes, reconnect and empty snapshot | convergence/apply duration, allocation/GC, business p99 disturbance, no stale routes | | AI/MCP | long streams, slow consumers, large results, cancellation, retry/failure | first-byte and first-content latency, total duration, heap/direct memory, FD usage and cleanup | Warm up the JVM, retain raw results and profiles, repeat runs and report variability. Compare both (a) resource cost/latency at equal successful throughput and (b) maximum sustainable throughput at the same stated latency/error limits. Verify upstream and generator capacity with a direct-upstream control. Do not change JVM, plugin set and production code simultaneously in a comparison. ## Observability prerequisite and existing implementation issues - [ ] #7637 — fix chain lifecycle timing; use a monotonic elapsed-time clock and distinguish response headers, first content and complete-stream latency in the benchmark. - [ ] #6574 — HTTP keep-alive default/reuse; validate compatibility instead of assuming historical latency estimates apply. - [ ] #6564 — condition pattern precompilation; validate current source and bounded cache/update behavior. Existing matching refactoring discussion: #6081. Candidate indexing or wider path-result caching is measurement-gated: preserve condition specificity/sort and test same path with different header/query/auth inputs, RESTful paths, no-match results, additions/deletions and priority changes. Do not simply enable path-only caching for mixed conditions. ## Independent optimization tasks - [ ] #7643 — Reduce routine matching and configuration-sync log volume - [ ] #7644 — Define bounded HTTP connection-pool and acquisition policies - [ ] #7645 — Batch namespace snapshot cache updates and invalidation - [ ] #7646 — Bound MCP tool-response capture memory and decoding costs - [ ] #7647 — Measure and bound upstream health-check round latency at scale - [ ] #7648 — Evaluate bounded parallel MCP remote-directory refresh - [ ] #7649 — Add and benchmark a minimal HTTP gateway distribution ## Additional measurement-gated candidates - AI Proxy already bounds header/idle/stream duration and response bytes, and stops retries after body emission. Measure per-chunk copies before proposing a DataBuffer ownership/API redesign. - HTTP body replay already buffers retryable request bodies with a limit. Measure large-POST plus retry memory; preserve exact replay, overflow handling and buffer release. Revisit retry eligibility/budgets only with explicit API semantics and compatibility. - Avoid blanket thread-pool increases or global scheduler changes. Use profiles and queue/event-loop metrics to locate actual blocking work, then isolate only that work. ## Delivery order and acceptance - [ ] Publish commands, fixtures, a baseline report and raw results for the workloads above (split into incremental PRs if needed). - [ ] First implementation batch: timing prerequisite, routine logs, connection reuse/capacity and condition precompilation. - [ ] Second batch: snapshot application and MCP result memory; health/catalog/assembly changes proceed when the corresponding workload justifies them. - [ ] Each implementation PR includes a same-environment before/after comparison and routing/timeout/retry/cancellation/configuration correctness regressions relevant to its change. - [ ] Overload and recovery are tested; improved peak QPS must not hide unbounded queues, resource growth or higher errors. - [ ] No low-cardinality metric is expanded with raw path/session/tool identifiers without an explicit cardinality budget. - [ ] Keep changes only when benefit exceeds run-to-run variation or a required resource bound is established; retain compatibility or document migration/rollback. Store ownership and release gates remain tracked by #7294/#7306, including etcd #7597 and Apollo #7599; this performance tracker does not duplicate that migration work. -- 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]
