HTTP-routing seems to go to the opposite end of the spectrum - the default is to use a dispersion of "1", which gives best cache efficiency as Ryan mentions. I think the behavior in this regard should be somewhat similar between HTTP and DNS routing.
__Jason On Mon, Dec 4, 2017 at 10:19 PM, Durfey, Ryan <[email protected]> wrote: > I like the idea of code that makes it always under the threshold and I > think this is a good feature to add, but from a practical perspective we > always want the max dns response to be the minimum viable for cache > efficiency. Most of our services (95%+) should be set to 1, 2, 3, or 4 > correlated to throughput of the service. Making the default set to as many > as possible ensures that unless you are paying close attention you will > have terrible cache efficiency. I would advocate for 2 or 3 since this > would cover the majority of our services, keep cache efficiency reasonable, > and work for most other applications as well. I would also advocate to add > the threshold check in case someone goes too high or sets it to 0. > > > > *Ryan Durfey* M | 303-524-5099 <(303)%20524-5099> > > CDN Support (24x7): 866-405-2993 <(866)%20405-2993> or > [email protected] > > > > > > *From: *Jason Tucker <[email protected]> > *Reply-To: *"[email protected]" < > [email protected]>, "[email protected]" < > [email protected]> > *Date: *Monday, December 4, 2017 at 3:10 PM > *To: *Phil Sorber <[email protected]> > *Cc: *"[email protected]" < > [email protected]> > *Subject: *Re: Changing max_dns_answers default > > > > I can't comment on the development effort for that (or the compute / > > latency overhead that it might add to TR), but I think having a default > > variable that could be set per TC installation doesn't seem unreasonable. > > > > __Jason > > > > On Mon, Dec 4, 2017 at 9:11 PM, Phil Sorber <[email protected]> wrote: > > > > What about adding code that would count the bytes dynamically and make > > sure it keeps under the threshold? Maybe even make that the behavior for > > the current default of 0. > > > > > > On Mon, Dec 4, 2017 at 2:06 PM Jason Tucker <[email protected]> > > wrote: > > > > Yes, this is the UDP thing. We've had customers with clients that sit > > behind DNS infrastructure that has problems with large response packets. > > > > However, the "max" is going to be installation dependent, though. > > Variables > > such as edge hostname convention, and CDN DNS domain suffixes are going to > > cause that threshold to vary from installation to installtion. If you have > > short FQDNS, you can fit many of them in a single UDP response. > > > > __Jason > > > > On Mon, Dec 4, 2017 at 9:00 PM, Phil Sorber <[email protected]> wrote: > > > > > You say it causes issues with "large cache groups". What is "large" in > > this > > > context? Maybe we should pick a default that puts us slightly below > > that. > > > Reading a little into your comment here, I assume the "problems" stems > > from > > > the number of answers that fit in a UDP packet. Maybe we should just > > make > > > the default below that threshold so we get as close to the max without > > > causing said problems? > > > > > > Thanks. > > > > > > On Mon, Dec 4, 2017 at 12:52 PM Volz, Dylan <[email protected]> > > > wrote: > > > > > > > Hi All, > > > > > > > > The max_dns_answers has been defaulted to 0, which is an unlimited > > number > > > > of answers, which causes issues for deployments with large cache > > groups. > > > I > > > > opened a PR (1611< > > > > https://github.com/apache/incubator-trafficcontrol/pull/1611>) to > > change > > > > the default from 0 to 5 which is hopefully a sensible value for most > > > > deployments. If this doesn’t seem like a sensible default please > > respond > > > > with alternatives. > > > > > > > > Thanks, > > > > Dylan > > > > > > > > > > > > > >
