Unless people have more questions/opinions, can I assume we are happy with this new routing/caching efficiency knob? I don’t see how this could negatively affect anything, besides complicating DS configuration further.
On 6/6/18, 2:50 PM, "Dremin, Sergey" <[email protected]> wrote: Hi Eric, The problem will materialize once we enable deep routing for non-live delivery channels with larger libraries. Those delivery channels need to be deep routed only to deep cache groups of sufficient size to make sure caching efficiency remains at acceptable levels. Right now that is not possible. They will be routed to any deep cache groups, even where there is a single server, resulting in poor caching efficiency, and more traffic to the mids. Does that explain the problem sufficiently? ~Sergey On 6/5/18, 7:10 PM, "Eric Friedrich (efriedri)" <[email protected]> wrote: Hey Sergey- What is the problem that you are experiencing here? I understand what you are proposing, but am not sure why this is needed. I would find some more details very useful Thanks, Eric > On Jun 5, 2018, at 5:40 PM, Dremin, Sergey <[email protected]> wrote: > > We should create an extension to the deep caching/deep routing field that will allow you to specify a minimum # of caches in a deep cache group for that deep cache group to be enabled for that DS. > > > > Cache group size is proportional to caching efficiency. Having a configurable value for a minimum # of caches for a DS would allow to change the caching efficiency for that DS versus the routing efficiency (that comes with deep routing) for that DS. > > > > Ideally this is something that is set based on current CDN performance. > > > > 1. A deep routing enabled DS with poor caching efficiency could use a bigger minimum size for a deep cache group. > 2. A deep routing enabled DS with not sufficient deep routing usage, could use a smaller minimum size for a deep cache group. > > > > Right now, we need to decide if we want to make this configurable or static. Since I think this will need to be configurable in the future anyway, so it a good idea to do it now. > > > > This will require changes to TO/TP and traffic router. > > Thoughts?
