Eric, good points, thank you.
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.
- No and true. I don't think I need this to be this complicated yet.
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?
- Yes, additional TR logic will be required to hand this properly.
On 6/8/18, 11:04 AM, "Eric Friedrich (efriedri)" <[email protected]> wrote:
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?
>
>
>
>
>
