Although I've seen higher duration of requests creating issues with ORT updating all our servers in the past, I think this one is required to move to HA. I'd like to see what's going to be the impact in a big production environment. Other than that. +1
On Tue, Jan 17, 2017 at 5:39 PM, Jeremy Mitchell <[email protected]> wrote: > Does anyone have a problem with me moving forward with > https://issues.apache.org/jira/browse/TC-68 > > Yes, this will increase the amount of time it takes for ORT to fetch > regex_revalidate.config (see my curl durations in previous response) but, > hopefully, the PR submitted by @dg4prez ( > https://github.com/apache/incubator-trafficcontrol/pull/141) plus a > caching > layer in front of TO will negate the additional latency. > > Why is this issue important? Without removing regex_revalidate.config from > the file system (it is currently stored > at public/Trafficserver-Snapshots/:cdn_name/regex_revalidate.config), it > makes it difficult to move to an HA TO (highly-available, redundant). > > Jeremy > > > > On Thu, Jan 5, 2017 at 4:42 PM, Jeremy Mitchell <[email protected]> > wrote: > > > derek gelinas is working on a PR that "scopes" these config files. i.e. > > some config files are at the server level, profile level or cdn level. > > regex_revalidate.config happens to be at the cdn level. Here is his PR > that > > I think will be targeted for 2.1. > > > > https://github.com/apache/incubator-trafficcontrol/pull/141 > > > > what this means is that if a server needs to fetch > > regex_revalidate.config, it would fetch it like this > > to-domain.com/api/1.2/cdn/cdn1/configfiles/ats/regex_revalidate.config > > and if this file is served from a cache of its own, the request by X > number > > of servers to get the same file would take advantage of caching to reduce > > the delivery time. sooo.....maybe it's a second the first time and a few > ms > > each subsequent time... > > > > hope that made sense. > > > > jeremy > > > > > > > > On Tue, Jan 3, 2017 at 7:05 PM, Steve Malenfant <[email protected]> > > wrote: > > > >> Jeremy, > >> > >> I missed this email. Seems like close to a second is quite slow. Is the > >> regex_revalidate.config per server? It seems like it was per CDN before. > >> > >> On Tue, Dec 13, 2016 at 1:02 PM, Jeremy Mitchell <[email protected] > > > >> wrote: > >> > >> > Obviously, it is going to be slower to pull regex_revalidate.config > >> thru TO > >> > as opposed to pulling it off the file system. The question is...is > this > >> > acceptable? > >> > > >> > curling to > >> > https://to.domain.com/Trafficserver-Snapshots/cdn- > >> > name/regex_revalidate.config > >> > > >> > time_namelookup: 0.005 > >> > time_connect: 0.058 > >> > time_appconnect: 0.000 > >> > time_pretransfer: 0.000 > >> > time_redirect: 0.000 > >> > time_starttransfer: 0.000 > >> > ---------- > >> > time_total: 0.063 > >> > > >> > curling to > >> > https://to.domain.com/genfiles/view/server-host- > >> > name/regex_revalidate.config > >> > > >> > time_namelookup: 0.005 > >> > time_connect: 0.062 > >> > time_appconnect: 0.307 > >> > time_pretransfer: 0.307 > >> > time_redirect: 0.000 > >> > time_starttransfer: 0.781 > >> > ---------- > >> > time_total: 0.781 > >> > > >> > On Mon, Dec 12, 2016 at 9:03 PM, Steve Malenfant < > [email protected]> > >> > wrote: > >> > > >> > > I'm OK with this. I think most of the revalidate functionality is > not > >> > well > >> > > understood here... I guess I need to look into the API since we are > >> using > >> > > the UI to issue revalidate today. > >> > > > >> > > On Mon, Dec 12, 2016 at 5:43 PM, Jeremy Mitchell < > >> [email protected] > >> > > > >> > > wrote: > >> > > > >> > > > I've created an issue to solicit some feedback regarding the > >> removal of > >> > > > regex_revalidate.config from the file system. If you are not > aware, > >> > > > regex_revalidate.config is the ATS config file used to "invalidate > >> > > > content". Storing regex_revalidate.config on the file system makes > >> it > >> > > > harder to set up a highly-available, redundant traffic ops. > >> > > > > >> > > > https://issues.apache.org/jira/browse/TC-68 > >> > > > > >> > > > Thanks! > >> > > > > >> > > > >> > > >> > > > > >
