Nir, You bring up a good point. If we can make the assumption that requests coming to a specific Traffic Router are actually somewhat local to that Traffic Router, we might be able to localize those "country-localized" clients to a cachegroup close to that particular Traffic Router. That would have the effect of spreading load around a country a bit better if the Traffic Routers were geographically distributed well. Maybe that could be Phase 2 of this effort, but how much can we rely on that assumption?
-Rawlin On Tue, Feb 13, 2018 at 1:27 PM, Rivas, Jesse <[email protected]> wrote: > Nir, > > This solution does not support that level of granularity. > > Jesse > > On 2/13/18, 11:43 AM, "Nir Sopher" <[email protected]> wrote: > > Hi, > > Can this solution support different value in different routers? > Taking TR localization into account, it might give better granularity. > > Nir > > On Tue, Feb 13, 2018 at 8:34 PM, Rawlin Peters <[email protected]> > wrote: > > > Yeah, this basically solves the problem where MaxMind knows a client > > is in the US (or another country) but doesn't know the state, city, > > zip, etc., so it's not a "true" miss. In that case MaxMind returns the > > geographic center of that country as the client's location, but we > > don't want to route those clients to the cache group closest to that > > location because it might not be the ideal cachegroup. By using this > > parameter we can shift this high volume of "US" traffic that is > > essentially being localized to a lake in Kansas to a cachegroup more > > capable of handling that load. And we can do this on a per-country > > basis because we can create multiple of these parameters (which we > > wouldn't be able to do if we just used the Default Miss Lat/Lon of a > > DeliveryService). > > > > -Rawlin > > > > On Tue, Feb 13, 2018 at 11:10 AM, Rivas, Jesse <[email protected]> > > wrote: > > > Steve, > > > > > > Using the miss location for the DS was a potential solution that we > > talked about. However, the miss location is intended for use when the > > client IP falls through MaxMind without any data. Since the default > > location doesn't fit this criteria, it was decided to use a profile > > parameter to preserve granularity. > > > > > > Jesse > > > > > > On 2/13/18, 11:06 AM, "Steve Malenfant" <[email protected]> wrote: > > > > > > Jesse, > > > > > > I'm not exactly sure how MaxMind return this default value but > would > > there > > > be a way to use the MISS location specified in the DS? Seems like > > that is > > > what it was intended for. > > > > > > Steve > > > > > > On Tue, Feb 13, 2018 at 12:42 PM, Rivas, Jesse < > > [email protected]> > > > wrote: > > > > > > > Hi all, > > > > > > > > > > > > > > > > At Comcast, we have been seeing a pattern of the same cache > group > > being > > > > overloaded nightly as traffic increases on the CDN. The cause > was > > > > determined to be a default location that the geolocation > provider > > MaxMind > > > > returns for client IPs that it does not have additional data > for. > > For the > > > > US, MaxMind returns a geolocation with the coordinates: > > 37.751,-97.822; > > > > this is a substantial amount of traffic that is all directed to > > the nearest > > > > cache group. > > > > > > > > > > > > > > > > The fix I have introduced is a new profile parameter for > > CRConfig.json > > > > named 'maxmind.default.override' in the format: > > > > '<countryCode>;<lat>,<long>'. When MaxMind returns a default > > location, the > > > > code checks for a parameter entry with the same country code. If > > an entry > > > > exists, the default location will be overwritten with the > > coordinates of > > > > the parameter. This allows users to determine where this traffic > > should be > > > > sent rather than using the cache group closest to the MaxMind > > default > > > > location. The new parameter supports multiple entries so that > > there can be > > > > override coordinates for more than one country. > > > > > > > > > > > > > > > > Here is the PR: https://github.com/apache/incu > > bator-trafficcontrol/pull/ > > > > 1866 > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > > > > > Jesse > > > > > > > > > > > > > >
