Hey Sergey-
I’m good with it in general. A few design considerations:
Have you considered using deep cache CG TB provisioned instead of # caches in
group?
Not all caches are created equal- 5 caches in CG1 maybe have half the
storage of 2 caches in CG2.
Does the state/availability of a cache impact TRs decision?
Is there a difference between a cache being REPORTED, REPORTED (and
overloaded by TM), OFFLINE, ADMIN_DOWN?
—Eric
> On Jun 8, 2018, at 12:41 PM, Dremin, Sergey <[email protected]> wrote:
>
> 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?
>
>
>
>
>
