[
https://issues.apache.org/jira/browse/TC-32?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15662467#comment-15662467
]
Derek Gelinas commented on TC-32:
---------------------------------
Upon further reflection and discussion, the api routes will be changed to three
primary routes:
{code}
$r->get("/api/$version/profiles/:id/configfiles/ats/#filename")->over(
authenticated => 1 )->to ( 'Configs/ApacheTrafficServer.pm#get_profile_config',
namespace => $namespace );
$r->get("/api/$version/servers/:id/configfiles/ats/#filename")->over(
authenticated => 1 )->to ( 'Configs/ApacheTrafficServer.pm#get_server_config',
namespace => $namespace );
$r->get("/api/$version/cdns/:id/configfiles/ats/#filename")->over(
authenticated => 1 )->to ( 'Configs/ApacheTrafficServer.pm#get_cdn_config',
namespace => $namespace );
{code}
As you can see, we've split the files into three types - configs based on the
CDN, configs based on the server, and configs based on the profile. Hostnames
or DB ids can be used in all three cases. ATS has been added to the route as
well, to allow for future CDN software integration beyond ATS.
The code also provides support for three actions, fetch, publish, and db.
Fetch is the default action. If the file requested exists on the filesystem,
it is returned. If the file does not exist, it is generated live from the DB
and returned. DB doesn't bother to check on the existing file, and generates
live data from the DB. Publish will write generate the file from the DB, write
it to the filesystem, and return the contents.
> Improve efficiency of ATS config generation
> -------------------------------------------
>
> Key: TC-32
> URL: https://issues.apache.org/jira/browse/TC-32
> Project: Traffic Control
> Issue Type: Improvement
> Components: Traffic Ops API
> Reporter: Derek Gelinas
> Assignee: Derek Gelinas
> Fix For: 1.9.0
>
>
> Currently when generating ATS configuration files, each server calls for its
> individual files from traffic ops. This is a very database-intensive process
> that is not scalable enough. I propose the following changes:
> 1) Generate the configuration files only as many times as needed - many files
> are the same (or can be) for the entire CDN or server profile.
> 2) Once generated, the files can be cached locally. Requests for the files
> by ORT will result in pulling down these cached files rather than many
> hundreds of DB queries each time.
> 3) Migrate the routes for these files to the API. Each call will have
> multiple options - a request made with no options would return the cached
> file, another option would return the current DB data, and a third option
> would update the cached file with the current information in the DB.
> 4) When an update is queued, generate and cache the configuration files, then
> activate the update flag for the relevant servers once the cached file
> generation is completed.
> In this way, triggering updates for the caches will result in an initial
> increase in activity as traffic ops generates the files needed, followed by
> the much lower impact of the files themselves being requested by the caches.
> I believe we can cut down the number of server-specific configuration files
> to only 5 intially, and potentially fewer by having ORT fill in certain
> fields on files like records.config with local data during processing.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
