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