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 <mitchell...@gmail.com> 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 <smalenf...@gmail.com> > 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 <mitchell...@apache.org > > > > 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! > > > > > >
