[GitHub] [trafficcontrol] rob05c commented on a change in pull request #4708: Add Blueprint for Cache Config Snapshots

[GitBox <gi...@apache.org>]

rob05c commented on a change in pull request #4708:
URL: https://github.com/apache/trafficcontrol/pull/4708#discussion_r428371457



##########
File path: blueprints/traffic-ops-cache-config-endpoint.md
##########
@@ -0,0 +1,155 @@
+<!--
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements.  See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership.  The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License.  You may obtain a copy of the License at
+
+    http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied.  See the License for the
+specific language governing permissions and limitations
+under the License.
+-->
+# Cache Config Snapshot
+
+## Problem Description
+
+Currently, ORT needs to request many large endpoints from Traffic Ops. These requests have a performance cost, and can cause issues for CDNs with many caches, running Traffic Ops or its PostgreSQL database on small hardware.
+
+The cache config generation doesn't need a lot of data, but there don't exist TO endpoints with only the data it does need, or a way to filter it.
+
+## Proposed Change
+
+Traffic Ops will add a “Cache Config Snapshot” feature.
+
+When the cache config is Snapshotted, all data will be serialized and stored, just like the CRConfig.
+
+Snapshot history will be stored. New snapshots will insert with a timestamp, retaining previous versions so they can easily be restored if necessary. Snapshots should be automatically pruned with a configurable number (which maybe be infinity or zero), and/or a configurable amount of time.
+
+The snapshot data will be cached in memory, with a configurable cache time (suggested default: 5s).

Review comment:
       TO Memory. I changed it to clarify.
   
   TO Memory reduces DB load, by making it so that when the Snapshot changes and 1000 caches request it at once, TO only has to make 1 DB request.
   
   ORT should also cache, once we have TO doing IMS. Which reduces load to each cache when the Snapshot hasn't change; but doesn't obviate the benefit of TO caching for when it has.




----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org