LB strategy that selects the fastest server based on the latest average response time. It's aimed to handle a multi datacenter setup where some server regularly need longer to response. It shall also detect short (subsecond) pauses of a server e.g. due to garbage collection or s.th. else.
The latest average response time is determined in the following order (the first found measure is used):
- currently still running requests (if they're lasting longer than previous, already completed requests)
- average response time of the current or the last second
- average response time of the last ten seconds
- total average resonse time
The response time is measured using the given testQuery. A dedicated test query is used, because queries can have very different performance characteristics, so that it might even be hard for an application to classify this. With the testQuery you have control what is used to measure response time.
For "normal" / "fast" servers (default: with a resonse time <= the average of all servers, you can override determineFastServers) test queries are run whenever a request comes in, but between test queries at least the minDelay has to be passed. This way servers are not hammered with requests when nobody else is using your search, but if there's high traffic this load balancer get high resolution of monitoring data to detect short pauses as well.
For "slow" servers (default: response time > average) tests are run using the specified maxDelay.
Directly after creation of this LoadBalancer / AsnycSolrClient multiple test queries are run (according to the specified initialTestRuns, by default 10) to have initial stats.
Value parameters
- clock
-
the clock to get the current time from. The tests using the maxDelay are run using a scheduled executor, therefore this interval uses the system clock
- collectionAndTestQuery
-
a function that returns the collection name and a testQuery for the given server. The collection is used to partition server when classifying "fast"/"slow" servers, because for different collections response times will be different. It's somehow similar with the testQuery: it might be different per server, e.g. some server might only provide a /suggest handler while others provide /select (which can be specified via the "qt" query param in the test query).
- filterFastServers
-
a function to filter fast / preferred servers. The function takes the calculated average duration of all servers of a collection, and returns a function for a SolrServer->Duration tuple that returns true/false to indicate if a server should be considered "fast". The default value for filterFastServers uses
duration <= average * 1.1 + 5(use 1.1 as multiplier to accepted some deviation, for smaller values like 1 or 2 millis also add some fix value to allow normal deviation). - initialTestRuns
-
on start each active server is tested the given number of times to gather initial stats and determine fast/slow servers.
- mapPredictedResponseTime
-
a function that's applied to the predicted response time. This can e.g. be used to quantize the time so that minor differences are ignored.
- maxDelay
-
the delay between tests for slow servers (or all servers if there are no real requests)
- minDelay
-
the minimum delay between the response of a test and the start of the next test (to limit test frequency)
- solrServers
-
solr servers to load balance, those are regularly tested.
Attributes
- Companion
- object
- Graph
-
- Supertypes
-
trait FastestServerLBJmxSupport[F]trait FastestServerLBMBeantrait AsyncSolrClientAware[F]trait LoadBalancertrait RequestInterceptorclass Objecttrait Matchableclass Any