loki/pkg/storage/chunk/client/congestion/hedge.go

package congestion

import (
	"net/http"

	"github.com/go-kit/log"

	"github.com/grafana/loki/v3/pkg/storage/chunk/client/hedging"
)

type NoopHedger struct{}

func NewNoopHedger(Config) *NoopHedger {
	return &NoopHedger{}
}

func (n *NoopHedger) HTTPClient(hedging.Config) (*http.Client, error) {
	return http.DefaultClient, nil
}

func (n *NoopHedger) withLogger(log.Logger) Hedger { return n }
Dynamic client-side throttling to avoid object storage rate-limits (GCS only) (#10140) What this PR does / why we need it: Across the various cloud providers' object storage services, there are different rate-limits implemented. Rate-limits can be imposed under multiple conditions, such as server-side scale up (ramping up from low volume to high, "local" limit), reaching some defined upper limit ("absolute" limit), etc. We cannot know apriori when these rate-limits will be imposed, so we can't set up a client-side limiter to only allow a certain number of requests through per second. Additionally, that would require global coordination between queriers - which is difficult. With the above constraints, I have instead taken inspiration from TCP's [congestion control algorithms](https://en.wikipedia.org/wiki/TCP_congestion_control). This PR implements [AIMD](https://en.wikipedia.org/wiki/Additive_increase/multiplicative_decrease) (Additive Increase, Multiplicative Decrease), which is used in the congestion _avoidance_ phase of congestion control. The default window size (object store requests per second) is 2000; in other words, we skip the "slow start" phase. The controller uses the Go [`rate.Limiter`](https://pkg.go.dev/golang.org/x/time/rate), which implements the token-bucket algorithm. To put it simply: - every successful request widens the window (per second client rate-limit) - every rate-limited response reduces the window size by a backoff factor (0.5 by default, so it will halve) - when the limit has been reached, the querier will be delayed from making further requests until tokens are available 2 years ago			`package congestion`

			`import (`
			`"net/http"`

Minor fixes to congestion control mechanism (#10319) What this PR does / why we need it: Minor logging / metric improvements to #10140 2 years ago			`"github.com/go-kit/log"`

chore: update loki modules for 3.0 release (#12433) Signed-off-by: Edward Welch <edward.welch@grafana.com> 2 years ago			`"github.com/grafana/loki/v3/pkg/storage/chunk/client/hedging"`
Dynamic client-side throttling to avoid object storage rate-limits (GCS only) (#10140) What this PR does / why we need it: Across the various cloud providers' object storage services, there are different rate-limits implemented. Rate-limits can be imposed under multiple conditions, such as server-side scale up (ramping up from low volume to high, "local" limit), reaching some defined upper limit ("absolute" limit), etc. We cannot know apriori when these rate-limits will be imposed, so we can't set up a client-side limiter to only allow a certain number of requests through per second. Additionally, that would require global coordination between queriers - which is difficult. With the above constraints, I have instead taken inspiration from TCP's [congestion control algorithms](https://en.wikipedia.org/wiki/TCP_congestion_control). This PR implements [AIMD](https://en.wikipedia.org/wiki/Additive_increase/multiplicative_decrease) (Additive Increase, Multiplicative Decrease), which is used in the congestion _avoidance_ phase of congestion control. The default window size (object store requests per second) is 2000; in other words, we skip the "slow start" phase. The controller uses the Go [`rate.Limiter`](https://pkg.go.dev/golang.org/x/time/rate), which implements the token-bucket algorithm. To put it simply: - every successful request widens the window (per second client rate-limit) - every rate-limited response reduces the window size by a backoff factor (0.5 by default, so it will halve) - when the limit has been reached, the querier will be delayed from making further requests until tokens are available 2 years ago			`)`

			`type NoopHedger struct{}`

			`func NewNoopHedger(Config) *NoopHedger {`
			`return &NoopHedger{}`
			`}`

Minor fixes to congestion control mechanism (#10319) What this PR does / why we need it: Minor logging / metric improvements to #10140 2 years ago			`func (n NoopHedger) HTTPClient(hedging.Config) (http.Client, error) {`
Dynamic client-side throttling to avoid object storage rate-limits (GCS only) (#10140) What this PR does / why we need it: Across the various cloud providers' object storage services, there are different rate-limits implemented. Rate-limits can be imposed under multiple conditions, such as server-side scale up (ramping up from low volume to high, "local" limit), reaching some defined upper limit ("absolute" limit), etc. We cannot know apriori when these rate-limits will be imposed, so we can't set up a client-side limiter to only allow a certain number of requests through per second. Additionally, that would require global coordination between queriers - which is difficult. With the above constraints, I have instead taken inspiration from TCP's [congestion control algorithms](https://en.wikipedia.org/wiki/TCP_congestion_control). This PR implements [AIMD](https://en.wikipedia.org/wiki/Additive_increase/multiplicative_decrease) (Additive Increase, Multiplicative Decrease), which is used in the congestion _avoidance_ phase of congestion control. The default window size (object store requests per second) is 2000; in other words, we skip the "slow start" phase. The controller uses the Go [`rate.Limiter`](https://pkg.go.dev/golang.org/x/time/rate), which implements the token-bucket algorithm. To put it simply: - every successful request widens the window (per second client rate-limit) - every rate-limited response reduces the window size by a backoff factor (0.5 by default, so it will halve) - when the limit has been reached, the querier will be delayed from making further requests until tokens are available 2 years ago			`return http.DefaultClient, nil`
			`}`
Minor fixes to congestion control mechanism (#10319) What this PR does / why we need it: Minor logging / metric improvements to #10140 2 years ago
			`func (n *NoopHedger) withLogger(log.Logger) Hedger { return n }`