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 >> > > >> > >> >
