Aias00 opened a new issue, #7824: URL: https://github.com/apache/shenyu/issues/7824
## Goal Evaluate and implement a lightweight HTTP proxy execution path when the effective rule retry count is zero, preserving the existing request, timeout and error semantics. Performance baseline/tracking: #7650. Reviewed revision: `04f7c2e8b7d282f14510157a9ab0bfaab538ecac` (`2.7.2-SNAPSHOT`). This is a source-grounded optimization candidate, not a measured production bottleneck or a promised latency improvement. ## Current work on each request - [AbstractHttpClientPlugin.java:102–115](https://github.com/apache/shenyu/blob/04f7c2e8b7d282f14510157a9ab0bfaab538ecac/shenyu-plugin/shenyu-plugin-httpclient/src/main/java/org/apache/shenyu/plugin/httpclient/AbstractHttpClientPlugin.java#L102-L115) selects and allocates a RetryStrategy and invokes its execute method even for retry=0. - [DefaultRetryStrategy.java:68–86](https://github.com/apache/shenyu/blob/04f7c2e8b7d282f14510157a9ab0bfaab538ecac/shenyu-plugin/shenyu-plugin-httpclient/src/main/java/org/apache/shenyu/plugin/httpclient/DefaultRetryStrategy.java#L68-L86) constructs/configures RetryBackoffSpec, computes a retry-sequence timeout and attaches retryWhen/error-mapping operators although no application retry can occur. - Fixed/exponential strategy paths likewise install retry machinery for a zero retry count. The original request and timeout/error handling remain necessary. This task concerns avoidable setup/allocation, not removing protection or changing retry eligibility. ## Scope and acceptance criteria - [ ] Benchmark retry=0 with a controlled local upstream, warm JVM and fixed successful request rate; record allocation bytes/request, CPU/request, throughput and p50/p95/p99. - [ ] Compare GET, small/large POST and streamed responses. Isolate this change from JVM, pool, logging and matching-cache changes. - [ ] Add a lightweight no-retry path only if its benefit exceeds run-to-run variation or materially lowers allocation/resource cost. - [ ] Preserve the current outcomes for each configured backoff type: success, upstream 4xx/5xx, connect/read timeout, generic errors, and cancellation. In particular, default strategy retry exhaustion currently performs status/error mapping even when the retry count is zero; do not blindly return the original publisher and change externally visible status codes. - [ ] Preserve rule timeout budgets, downstream execution, tracing and cancellation. Assert a single application-level outbound attempt for retry=0 and no body replay-cache initialization. - [ ] Keep retry>0 current/failover behavior and body-replay limits unchanged, with regression coverage. - [ ] Retain raw benchmark commands/configuration/results and report observed tradeoffs. Do not add production dependencies for the benchmark. ## Related work #6413 covers correct replay of retryable request bodies; #7752 covers non-default failover strategy behavior. Neither removes zero-retry setup cost. This task does not duplicate connection reuse/capacity work (#6574, #7644), nor claim to reduce upstream execution time. -- 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]
