c-ares / c-ares / #1086 / 1
92%
main: 92%

DEFAULT BRANCH: main
Ran
Files 158
Run time 3s
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst
coverage: 89.18% (+0.03%) from 89.154%
#1086.1

push

travis-ci

web-flow 
Automatic query timeout adjustment based on server history (#794)

With very little effort we should be able to determine fairly proper
timeouts we can use based on prior query history. We track in order to
be able to auto-scale when network conditions change (e.g. maybe there
is a provider failover and timings change due to that). Apple appears to
do this within their system resolver in MacOS. Obviously we should have
a minimum, maximum, and initial value to make sure the algorithm doesn't
somehow go off the rails.

Values:
 - Minimum Timeout: 250ms (approximate RTT half-way around the globe)
- Maximum Timeout: 5000ms (Recommended timeout in RFC 1123), can be
reduced by ARES_OPT_MAXTIMEOUTMS, but otherwise the bound specified by
the option caps the retry timeout.
- Initial Timeout: User-specified via configuration or
ARES_OPT_TIMEOUTMS
- Average latency multiplier: 5x (a local DNS server returning a cached
value will be quicker than if it needs to recurse so we need to account
for this)
- Minimum Count for Average: 3. This is the minimum number of queries we
need to form an average for the bucket.

Per-server buckets for tracking latency over time (these are ephemeral
meaning they don't persist once a channel is destroyed). We record both
the current timespan for the bucket and the immediate preceding timespan
in case of roll-overs we can still maintain recent metrics for
calculations:
 - 1 minute
 - 15 minutes
 - 1 hr
 - 1 day
 - since inception

Each bucket contains:
 - timestamp (divided by interval)
 - minimum latency
 - maximum latency
 - total time
 - count

NOTE: average latency is (total time / count), we will calculate this
dynamically when needed

Basic algorithm for calculating timeout to use would be:
 - Scan from most recent bucket to least recent
- Check timestamp of bucket, if doesn't match current time, continue to
next bucket
- Check count of bucket, if its not at least the "Minimum Count... (continued)

9042 of 10139 relevant lines covered (89.18%)

4293.52 hits per line

Source Files on job #1086.1