yangjj-iso opened a new pull request, #7653:
URL: https://github.com/apache/shenyu/pull/7653

   Refs #7644; performance program #7650. This draft implements the HTTP pool 
policy and its controlled capacity experiment. The issue remains open while the 
remaining measurement gates below are completed.
   
   `FIXED` already has an effective Reactor queue limit, but the factory cannot 
configure it. `ELASTIC` forces effectively unlimited connections/queueing and 
ignores the configured limits. Cancelled HTTP acquisitions can also occupy a 
queue slot until timeout with the pinned Reactor client.
   
   - Add `shenyu.httpclient.pool.pendingAcquireMaxCount`; omission preserves 
FIXED's existing effective `2 * maxConnections` limit, with overflow-safe 
derivation. Positive counts bound the queue; `-1` is an explicit legacy opt-in.
   - Make ELASTIC honor the configured connection count, queue capacity and 
acquisition timeout. Preserve its configuration identifier and document the 
behavior change, sizing, migration and rollback in the release note and 
capacity guide.
   - Propagate request-scoped cancellation into pending provider acquisitions, 
including when metrics are disabled. Dispose the factory-owned provider on bean 
destruction.
   - Reuse Reactor's active/idle/pending/limit gauges. Add opt-in acquisition 
timing with four fixed outcomes and a static pool-name tag, distinguishing pool 
acquisition timeouts from response read timeouts. Micrometer core remains 
optional; the default client was also started in a separate JVM without it.
   - Add a test-source-only controlled HTTP/SSE upstream and streaming 
forwarder, external constant-arrival-rate k6 harness, immutable compiled 
snapshots, JFR capture and reproducible report generation. No benchmark 
dependency is added to the production runtime. Keep-alive's production default 
remains owned by #6574.
   
   ### Validation
   
   - 86 tests passed: all 51 HTTP plugin tests and 35 HTTP starter tests, with 
zero failures/errors/skips. Coverage includes overflow, timeout, prompt 
cancellation with metrics on/off, active/stream cancellation and recovery, 
keep-alive reuse, H2C compatibility, metrics outcomes, property binding and 
invalid/overflowing queue counts.
   - Checkstyle and Apache RAT passed for the affected reactor; Python syntax 
and `git diff --check` passed.
   - All 48 controlled load runs completed: eight cases, three repetitions, 
baseline and candidate; 5 s warmup + 8 s fixed-arrival measurement per case. 
Zero generator dropped iterations and zero dropped queue samples. Both arms' 
actual Java 21.0.9 runtime was verified from JFR; build/tests used Java 21.0.10.
   - At 160 offered requests/s to a 100 ms upstream, FIXED median successful 
throughput was 73.44 → 73.74/s, successful-only p99 325.76 → 191.50 ms, and 
sampled queue peak 16 → 4. Errors were 52.30% → 53.24%: this is an explicit 
shorter-queue policy, not a peak-QPS claim.
   - ELASTIC median sampled open upstream connections were 49 → 8; the 
candidate shed excess load under the 8-connection/4-waiter budget. The 
unchanged AI-client construction control was measured separately with 1 s 
streams. Raw summaries, successful latency samples, pending lifetimes, CPU, 
heap/direct-memory, socket and Windows-handle observations are retained.
   
   [Capacity and migration 
guide](https://github.com/yangjj-iso/shenyu/blob/da06e7d9c/docs/performance/http-connection-pools.md)
 · [Measured 
report](https://github.com/yangjj-iso/shenyu/blob/da06e7d9c/docs/performance/http-pool-results.md)
 · [Raw primary 
samples](https://github.com/yangjj-iso/shenyu/blob/da06e7d9c/docs/performance/http-pool-samples.json)
   
   ### Remaining measurement gates
   
   Keep this draft pending Linux FD validation, longer dedicated-host 
p99/error-SLO rate sweeps and full gateway/TLS/AI-engine capacity validation. 
The current experiment colocates generator/upstream/forwarder on Windows; 
Windows process handles are recorded separately and are not reported as POSIX 
FD counts. Sampled heap peaks do not establish long-term memory stability. 
Full-repository Maven install and Docker E2E were not run locally.
   
   - [x] Read the contribution guidelines.
   - [x] Submit regression tests and reproducible measurements.
   - [ ] Full local `./mvnw clean install -Dmaven.javadoc.skip=true` 
(affected-reactor validation above).
   


-- 
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]

Reply via email to