Confirmed users
2,456
edits
ReleaseEngineering/Applications/Proxxy: Difference between revisions
Jump to navigation
Jump to search
ReleaseEngineering/Applications/Proxxy (view source)
Revision as of 13:56, 22 July 2015
, 22 July 2015→Operations: Adding some more operations documentation
Gmiroshnykov (talk | contribs) (Removed obsolete details about ansible and packer, added info on forcing cache refresh) |
(→Operations: Adding some more operations documentation) |
||
| Line 36: | Line 36: | ||
== Operations == | == Operations == | ||
=== Purging the cache === | |||
You can force cache refresh for a specific URL by requesting it from one of the build machines with <code>X-Refresh: 1</code> header, like this: | You can force cache refresh for a specific URL by requesting it from one of the build machines with <code>X-Refresh: 1</code> header, like this: | ||
| Line 43: | Line 43: | ||
In case of emergency, you can also invalidate all cache for a specific domain (or all domains) by manually SSHing into proxxy instances and <code>rm -rf</code>ing corresponding directories from <code>/var/cache/proxxy</code>. | In case of emergency, you can also invalidate all cache for a specific domain (or all domains) by manually SSHing into proxxy instances and <code>rm -rf</code>ing corresponding directories from <code>/var/cache/proxxy</code>. | ||
You should be careful as this may create a thundering herd problem for downstream servers. | You should be careful as this may create a thundering herd problem for downstream servers. | ||
=== Restarting / taking offline === | |||
The proxxy machines can be restarted safely. Clients will retry and fallback to other servers, or the canonical URL. | |||
If the machines are offline for too long, it can result in high network bandwidth and load on origin servers. Extended downtime should be coordinated with RelEng. | |||
=== Logs === | |||
Logs are sent to papertrail | |||