nagisa-kunhah opened a new pull request, #3347:
URL: https://github.com/apache/dubbo-go/pull/3347
### Description
Fixes #3336
### Progress:
- [x] Review the current adaptive throttling capability in dubbo-go
- [x] Run pressure tests to understand its capability limits
- [ ] Move the adaptive service plugin to dubbo-go-extensions
- [ ] Add dubbo-go-samples for adaptive service
### Pressure tests
#### Test scenario
- `samples/adaptive_service/protect_provider/{server,client}`: verifies
provider protection under high client concurrency by tracking rejects and
server-side max active requests.
- `samples/adaptive_service/rtt_shrink/{server,client}`: verifies limiter
behavior across fast/medium/slow RTT stages and records
limitation/remaining/inflight changes.
- `samples/adaptive_service/p2c_healthy/{server,client}`: verifies
multi-provider adaptive P2C routing by comparing per-provider hit ratio and
remaining capacity.
#### Test results
:white_check_mark: **protect_provider**：
- Config: 200 client concurrency, 200ms provider handler delay, 30s duration.
- Result: client sent 243,940 requests in total; 222,720 were rejected by
adaptive service, `failed=0`, reject rate was about 91%. The provider business
handler only processed about 21,020 requests, and rejected requests did not
enter the handler.
- Conclusion: provider-side adaptive throttling can shed overload traffic
before the business handler and keeps unexpected RPC failures at zero under
high concurrency.
:warning: **rtt_shrink**：
- Config: 200 client concurrency, staged provider handler delay
`fast:20ms:30s, medium:100ms:20s, slow:500ms:40s`, 90s duration.
- Result: the staged delay switch worked as expected. Client-side latency
increased with each phase: the fast phase stayed around tens of milliseconds,
the medium phase rose to about 100ms, and the slow phase rose to about 500ms.
`failed=0` throughout the run. The limiter was found and reported continuously
by the provider stats endpoint. During the fast phase, `limiter_limitation`
grew from about 55 to a peak of about 123. **However,** after RTT increased to
the 500ms slow phase, `limiter_limitation` stayed around 122 and did not drop
meaningfully below the fast-phase peak. Rejections increased continuously under
the high offered load, reaching about 888,000 total rejects by the end of the
run.
:white_check_mark: **p2c_healthy**：
- Config: three providers with different handler delays: `fast=20ms`,
`medium=100ms`, `slow=300ms`; 200 client concurrency; 90s duration; adaptive
cluster + P2C load balancing enabled.
- Result: P2C quickly avoided the slow provider after warmup. The final
cumulative traffic distribution was about `fast=44%`, `medium=54%`, and
`slow=1.8%`, with `failed=0`. The slow provider's interval traffic dropped to 0
later in the test. The medium provider was repeatedly selected as the
healthiest node because its reported `remaining` capacity was higher; it
reached `limiter_limitation=500`, while the fast provider stayed around 200.
- Conclusion: P2C can use adaptive service metrics to bias traffic away from
unhealthy providers and toward nodes with higher remaining capacity. One caveat
is that the 100ms provider received more traffic than the 20ms provider, which
points to a possible HillClimbing expansion/parameter issue rather than a P2C
selection failure.
### Checklist
- [x] I confirm the target branch is `develop`
- [x] Code has passed local testing
- [x] I have added tests that prove my fix is effective or that my feature
works
--
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]
