feat: auto concurrency limiter of adaptive service #2114
Conversation
|
This concurrency limiter uses CPU load as a limit switch to automatically calculate the capacity of the service when the load is too high, the effect is as follows.
QPS increases gradually over time. When the CPU load is high, flow limiting is automatically turned on. Then successful requests and CPU load are maintained at a relatively stable level. |
|
|
||
| exploreRatio float64 | ||
| emaFactor float64 | ||
| noLoadLatency float64 //duration |
There was a problem hiding this comment.
nit: //duration -> // duration
| startSampleTimeUs int64 | ||
| lastSamplingTimeUs *atomic.Int64 | ||
| resetLatencyUs int64 // time to reset noLoadLatency | ||
| remeasureStartUs int64 //time to reset req data (sampleCount, totalSampleUs, totalReqCount) |
| defer func() { | ||
| ticker.Stop() | ||
| if err := recover(); err != nil { | ||
| go cpuproc() |
There was a problem hiding this comment.
Add a warning log to let users know what is happening here.
| SampleWindowSizeMs = 1000 | ||
| MinSampleCount = 40 | ||
| MaxSampleCount = 500 | ||
| CpuDecay = 0.95 |
| } | ||
| } | ||
|
|
||
| func CpuUsage() uint64 { |
|
Kudos, SonarCloud Quality Gate passed!
|
|
@nanfeng1999 lizhenyuan |
|
Merged into |
What this PR does:
Provides an auto concurrency limiter in unstable environments.
This is a component of adaptive service at the provider side.
The component at the consumer side is in #2067.
Which issue(s) this PR fixes:
Fixes #1834
You should pay attention to items below to ensure your pr passes our ci test
We do not merge pr with ci tests failed