NackAdmissionFilter
Related Docs:
object NackAdmissionFilter
| package filter
Size of moving window for exponential moving average, which is used to keep track of the ratio of nacked responses to accepted responses and compute the client's accept rate. E.g., if set to 1 second, then only requests occurring over the previous second will be used to calculate the EMA. The window size influences how the EMA behaves in roughly the following ways: - an EMA with a shorter window duration will respond more quickly to changes in cluster performance, but will keep a less accurate estimate of the long-term average accept rate; - an EMA with a longer window duration will respond more slowly to changes in cluster performance, but will keep a more accurate estimate of the long- term average accept rate.
Constant which determines how aggressively the filter drops requests. For example, if set to 1/2, then the highest nack rate the filter will tolerate before probabilistically dropping requests is 50%; if set to 1/3, then the highest nack rate tolerated is 33.3%. In general, if set to x, the highest nack rate tolerated is x.
Random number generator used in probability calculation.
Convert the Filter.TypeAgnostic filter to a Filter and chain it with
andThen.
Convert the Filter.TypeAgnostic filter to a Filter and chain it with
andThen.
Terminates a filter chain in a ServiceFactory.
Terminates a filter chain in a ServiceFactory. For example,
myFilter.andThen(myServiceFactory)
a service factory that takes the output request type and the input response type.
Terminates a filter chain in a Service.
Chains a series of filters together:
Chains a series of filters together:
myModularService = handleExceptions.andThen(thrift2Pojo.andThen(parseString))
another filter to follow after this one
synchronously thrown exceptions in the underlying service are automatically lifted into Future.exception.
Conditionally propagates requests down the filter chain.
Conditionally propagates requests down the filter chain. This may useful if you are statically wiring together filter chains based on a configuration file, for instance.
a tuple of boolean and filter.
This is the method to override/implement to create your own Filter.
This is the method to override/implement to create your own Filter.
a service that takes the output request type and the input response type
This filter probabilistically drops requests if the nack rate exceeds the
nackRateThreshold. In the case that most or all of the cluster which the client is speaking to is overloaded, this will help the cluster cool off.The implementation of this filter is heavily inspired by Chapter 21, section "Client-Side Throttling" of O'Reilly's "Site Reliability Engineering: How Google Runs Production Systems", by Beyer, Jones, Petoff, and Murphy, 1e.
NOTE: Here is a brief summary of the configurable params.
A configuration with a
nackRateThresholdof N% and awindowof duration W roughly translates as, "start dropping some requests to the cluster when the nack rate averages at least N% over a window of duration W."Here are some examples of situations with param values chosen to make the filter useful:
- Owners of Service A examine their service's nack rate over several days and find that it is almost always under 10% and rarely above 1% (e.g., during traffic spikes) or 5% (e.g., during a data center outage). They do not want to preemptively drop requests unless the cluster sees an extreme overload situation so they choose a nack rate threshold of 20%. And in such a situation they want the filter to act relatively quickly, so they choose a window of 30 seconds.
- Owners of Service B observe that excess load typically causes peak nack rates of around 25% for up to 60 seconds. They want to be aggressive about avoiding cluster overload and don’t mind dropping some innocent requests during mild load so they choose a window of 10 seconds and a threshold of 0.15 (= 15%).