►
From YouTube: Scalability Meeting: Redis Repository Cache
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
There
you
go
so
we're
going
to
talk
about
the
implementation
plan
of
extracting
a
piece
that
is
currently
stored
in
redis
cache
into
a
new
redis
instance.
The
piece
we've
chosen
for
that
is
everything
that
is
currently
read
from
italy.
So
that's
files,
branch
names,
tag,
names,
references
all
of
that
stuff
yeah
and
we'll
move
that
out
into
a
new
a
new
instance
in
the
google
doc.
I've
outlined
the
plan,
I've
populated
all
issues
in
in
the
epic.
A
I
do
think
that
when
we
start
working
through
this,
then
more
things
will
pop
up
or
we're
going
to
split
some
things
out
into
more
issues
but
yeah.
I
thought
that
was
a
good
first
start.
The
the
things
that
I
know
more
about
are
more
fleshed
out.
So,
for
example,
that's
probably
more
for
the
both
of
you,
like
you,
probably
know
more
about
this,
but
everything
to
to
spin
up
a
new
cluster.
I
have
no
idea
how
that
works.
A
I've
seen
a
little
bit
of
it
in
demos
and
so
on,
like
where
eager
was
using
tanka
to
to
deploy
them.
But
I
have
no
idea
is.
C
There's
there's
one
other
cluster
that
we're
working
on.
Actually,
the
initial
intent
was
to
do
rate
limiting,
and
I
think
the
gold
has
shifted
there
to
to
a
cache
for
registry
because
they
need
it
sooner,
but
but
yeah
we'll
this.
This
is
this
is
green
field.
Work.
B
C
A
C
It
doesn't
have
to
be,
but
it's
since
that's
the
direction
we're
going.
We
figured
we'd,
give
it
a
shot.
Is
that
still
where
we're
at
bob.
A
That's
kind
of
the
idea
like,
and
it's
also
my
understanding,
the
the
intention
of
the
work
is
that
that
it's
much
easier
for
everybody
to
spin
up
a
cluster.
So
as
far
as
we
get
doing
this
stuff
like
we're
going
to
have
to
involve
the
people
that
know
this
better
because
it's
as
you
mentioned
greenfield
like
not
everything
is
as
configurable
as
we
need
it
to
be
yet
and
like
all
of
that,
but
I
think
it's
yeah
a
good
start.
So,
if
possible,
I
would
deploy
like.
B
My
only
my
only
question
about
that
was,
I
mean
obviously,
given
the
choices
doing
this
in
kubernetes
and
not
having
to
transition
it
in
the
future
would
be
better.
The
question
was
just
timing.
Like
can
we
wait,
however
long?
We
have
to
wait
to
have
a
functional
environment
and
it
sounded
like
from
igor's
demo
last
week
that
it
was
maybe
a
month,
maybe
two
months.
C
Yeah,
we
really
don't
know
so,
let's
take
a
moment
to
talk
about
the
ttl
piece
or
I
guess
the
reducing
the
memory
footprint
since
we
talked
about
that
as
ttl
initially
and
looking
over
the
the
the
issues
bob
that
you've
made,
it
looks
like
two
of
the
three
of
them
were
suggesting:
switching
to
e-tag.
C
A
A
It's
just
like
looking
at
the
implementation,
these
things
are
taking
up,
storage
and
they're
they're
not
shared
across
across
users
so
and
they
they
are
for
our
like
front
end,
not
not
the
cache.
So
that
could
be
not
the
api
or
anything
fancy
like
that.
So
that
seemed
like
a
good
thing
to
sit
to
set
in
front
like
there's
that
the
four
pieces
that
we're
talking
about
represent
about
12
to
15
percent
of
storage
used
in
the
sample
that
I
took
so
everything
together.
A
We
should
super
open
optimistically,
get
gain
about
40
percentage,
but
one
of
the
issues
I've
created
was
harder
like
that
was
the
highlight
guys.
It's
it's
like
a
proper
cache.
It's
it's
shared,
but
it's
yeah
code,
that's
stored
in
in
red,
so
it's
just
big
and
there
I've
I've
mentioned
reducing
ttl
like
do
it
for
a
few
hours.
I
mentioned
eight
hours,
I
think,
from
down
from.
A
A
The
yeah,
the
problem
with
the
the
short
amount
of
time
like
I
took
a
snapshot
at
a
certain
time.
I
it
took
about
two
wish
hours
to
get
that
snapshot,
so
we
only
have
data
from
that.
So
I
like
it's,
not
really
an
excellent
measure
to
see
if
that
would
be
enough
to
to
reduce
the
growth
of
the
like,
reduce
the
memory.
B
C
Yeah,
that's
that's
one
of
the
topics
I
I
kind
of
wanted
to
casually
talk
about.
I
have
a
couple
of
really
really
rough
ideas
for
how
we
could
try
to
estimate
how
much
memory
we
need
to
shed
to
get
underneath
the
the
maximum
limit.
C
A
One
of
the
things
that
I
brought
up
in
this
epic
is
adding
metrics
of
bytes
bytes
written
by
its
red
for
this
specific
piece
of
the
of
the
cache
like
for
this
specific
piece
of
data.
Yes,
because
that
should
give
us
an
estimate
like
if
it
comes
in
at
this
many
megabytes
an
hour,
and
we
want
to
keep
it
for
this
long.
We
need
to
have.
C
Yeah,
so
one
of
one
of
the
one
of
the
other
pieces,
that's
missing
from
that
equation
is
the
rewrites
to
to
the
same
cache
key.
So
if
you
know
kifu
gets
written
once
and
then
before
it
it's
tc
and
the
ttl
is
fixed
at
time
at
either
the
time
key
is
added
or
or
potentially
subsequently,
by
an
expire
command.
I
don't
know
what
keys
usex.
You
know
we
we
actually
run
expire
commands
on,
but
we
are
running
some.
C
You
know
a
small
number
of
expires
to
explicitly
adjust
ttl
settings.
C
C
Yeah
so
yeah
like
and
the
rewrite
case,
even
without
expire
adjustments,
is,
is
kind
of
an
opaque
thing,
so
I'm
not
sure
how
to
account
for
that
in
terms
of
interpreting
the
the
values.
Apart
from
just
assuming
that,
that's
that
that's
you
know
just
allowing
that
to
be
an
error
factor
and.
A
My
question
like
is,
that
is
that
safe
to
do
the
thing
is
like
right
now
most
of
these
cash
things
have
a
ttl
of
one
week,
so
adjust
it
from
the
default
of
two
weeks
down
to
one
week,
but
I
was
mentioning
on
the
issue
like
if
we,
if
we
allocate
an
instance,
let's
aim
for
a
day
and
after
this
project
like
when
everything
is
using
this
new
cache,
I'm
going
to,
I
would
start
a
project
to
lower
everything
like
the
whole
ttl
to
something
more
in
the
range
of
hours
and
not
in
days,
because
I
think
that
makes
more
makes
more
sense
for
this
kind
of
cash.
A
For
the
new
cash,
yes,
because
then
we
can
work
on
a
limited
set.
A
little
bit
like
rails.cash
is
huge
because
everything
goes
in
there
from
everywhere.
So
this
is
like
a
slice
that
we're
taking
out,
and
we
know
that
it
sits
in
front
of
italy,
and
we
know
that,
like,
for
example,
gitly
is
not
the
database,
so
that
means
it
is
already
sharded
out.
Yes,.
C
Yes,
okay,
do
you
remember
what
time
of
day
I'm
thinking
about
the
the
the
snapshot
that
you
captured?
Do
you
remember
what
what
time
of
day
and
day
of
week
that
was.
C
Oh
june
26th,
oh
no,
that
was
when
the
analysis
was
run.
I
mean
29th.
C
A
Okay
june
16th,
okay
and
I
was
finished
with
it
at
my
six.
So
that's
for
utc,
okay,.
C
Okay,
that's
a
that's
a
that's
a
yeah.
My
my
vague
recollection
was
that
we
we
captured
this
during
during
a
heavy
during
a
relatively
heavy
time
of
day,
we're
generally
depending
on
I
mean,
and
I
need
what
what
day
of
the
week
was
this.
This
was.
This
was
a
weekday
right.
C
Great
great
great,
that's
great
yeah.
I
tend
to
shy
away
from
fridays
because
the
workload's
a
little
lighter
than
other
weekdays,
but
yeah
generally
weekly
days,
starting
starting
around
an
hour
or
so
ago.
We
tend
to
get
you
know
like
within
80
of
the
daily
wheat
daily
peak.
So
that's
that's!
That's
a
that's
a
great
time
to
do
the
capture
fantastic.
Do.
C
I
don't
think
it
would
be
dramatically
different,
but
we
can
have
more
since,
since
what
we're
aiming
for
is
is
peak
usage.
This
is
this
is
real
close
anyway,
so
yeah
yeah,
it's
it
just
takes
takes
it
boosts
the
confidence.
That's
all
I'm
really
thinking
on
that
note,
though,
one
of
the
again
these
are
super
super
duper
rough
ideas.
C
One
of
the
ideas
I
had
for
trying
to
estimate
how
much
memory
we
need
to
shed
was
to
temporarily
raise
max
memory
for
for
a
few
hours
during
the
the
during
the
the
daily
minimum,
the
the
trough
in
in
the
in
the
memory
cycle,
and
we
can
see
exactly
when
that
when
that
is,
but
we
we
still
hit
saturation
just
not
as
frequently
so
if
we
raise
max
memory
by
you
know,
I'm
making
this
up
by
20.
C
C
Yes,
neither
am
I
I
don't
think
we
would
have
done
it
like
and
to
kind
of
to
that
end,
my
even
more
kind
of
silly
sounding
half-baked
idea
was
the
the
the
slope
of
yes.
C
Yes,
the
closer
we
get
to
to
a
slope
of
to
a
horizontal
slope
of
zero,
the
the
closer
we
we
can
infer
that
the
closer
we
are
for
and.
B
In
that
case,
you're
talking
about
the
slope
between
between
two
how.
B
A
A
C
B
The
other
thing
that's
probably
worthwhile
to-
and
I
saw
that,
there's
a
linked
issue
off
of
one
of
the
infra
dev
issues-
is
to
also
get
more
metrics
around
hits
and
misses.
Specifically,
specifically,
those
like
misses
are
useful
and
hits
are
useful
and
both
together
give
us
a
lot
of
information
on
things
in
the
ttl
that
we
could
be
changing.
I've.
A
C
So
on
yes
on
on
that
note,
if
we
also,
I
don't
know
that
we
can
afford
to
do
this
for
every
for
for
every
cash
key,
but
for
for
cash
keys.
That
were
that
we
that
we
find
particularly
interesting
for
for
whatever
reason
like
like
the
the
the
cash
key
patterns
that
represent
a
large
byte
count
like
like
we're
focusing
on.
We
could
also
try
to
capture
the
the
during
during
a
cache,
miss
events.
It
would
be
fantastic
to
have
the
the
client
code
capture.
C
C
A
C
C
A
B
C
C
C
A
Would
have
like
we'd
add
the
long.
C
A
A
B
That
seems
like
a
really
useful
thing
to
have
overall,
rather
than
play
the
game
of
what
key
is
related
to
what
thing
I
think
bob
also
mentioned
at
one
point
like
front
loading,
some
of
the
useful
key.
B
B
A
I
think
now,
when,
when
we
spin
up
a
new
one,
let's
just
do
it
better
for
the
new
one
yeah,
but
that
would
require
changing
all
the
keys
and
that's
an
application
change.
Maybe
it's
not
worth
touching.
A
Yeah,
that's
another
thing
that
I
wanted
to
discuss
with
the.
C
A
A
C
B
B
C
C
I
spent
about
an
hour
talking
through
the
various
failure
modes
associated
with
this,
with
with
igor,
I
think,
last
week,
and
there
there's.
There
are
a
lot
of
subtle
cases
that
we
need
to
address
and
and
that
that's
stephanie,
that's
that's
one
of
them
that
you've
just
highlighted
right.
C
I
think,
because
we
could
we
could
just
to
kind
of
play
that
scenario
out
if
we
having
having
two
two
two
canonical
sources
for
for
ostensibly
the
same
data,
we
start
with
a
the
the
current
cache
and
switch
to
b.
If
we
switch
back
to
a
at
that
point,
we
have
exposed
some
stale
cache
keys
and
without
without
knowing
the
specific
application
logic.
This
is
not
unknowable.
This
is
not
a
solvable
problem
without
knowing
the
specific
application
logic
for
every
one
of
those
cache
keys.
B
C
To
be
read,
acted
upon
with,
you
know,
through
arbitrary,
you
know,
application
logic
and
and
have
cascading
side
effects
that
I
I've
personally
worked
through
scenarios
where
that
damaged
other
data
by
propagating
stale
values
in
appropriate
ways.
I
think.
C
A
C
C
B
A
The
cash
keys
are
yeah,
the
cash
keys
start
with
the
method.
Name,
that's
a
variable.
The
method
name
is
the
thing
that
we're
caching
does.
This
repository
exist,
the
name
right
file,
the
whatever
and
then
later
on
in
is
somewhere
in
the
cache
key
is
the
project.
So,
if
that
flipped
around,
we
would
have
an
easier
time,
but
it's
not
so
we
don't
right.
C
One
thing
we
talked
about
is:
if
we
know
the
the
the
ttl
for
these
cache
keys
for
all
of
the
keys
that
were
moving
to
the
to
the
new
cache
instance.
We
could
have
a
rule
that
says
that
we
can
safely
fail
back
after
waiting.
The
the
ttl
duration.
A
C
A
C
And
it
may
be
reasonable,
like
like
we
do
with
with
dns
changes.
It
may
be
reasonable
to
temporarily
reduce
the
ttl
for
this
trend
to
to
accommodate
this
transitional
state
to
allow
failback,
for
you
know,
after
a
shorter
time
span,.
A
The
problem
is
that
we
then
for
this
transition.
We
we
shorten
the
ttl
for
everything,
not
just
for
the
projects
that
were
already
or
that
we're
going
to
select.
C
A
C
B
A
A
A
I
think
I
think
we
should
do
the
the
lower
to
one
day
for
all
of
these
things.
He
all
of
things
here,
because
most
of
it's
already
like
that
changing
the
outliers,
it's
just
going
to
make
it
safer
than
we
just
need
to.
If
we
decide
that
something
is
not
performant
enough
with
the
cash
in
the
beginning,
then
we
know
that
this
one
day
is
the
safe
thing
to
do.
A
It's
still
a
long
time.
I
think,
though,.
B
C
A
Abused.
Yes!
So
when
we
do
that,
one
that
goes
well,
I'm
pretty
confident
that
we'll
be
able
to
carry
on.
C
From
from
a
performance
assessment
standpoint.
B
I
don't
I
mean
so
I
guess
my
first
question
is
follow-ups
spin
up
a
new
cluster
like
I
I
I
can
happily
help
follow
up
on
some
of
these
matt
can
help
follow
up
on
some
of
these.
Are
there
people
we
need
to
talk
to?
Are
there
things
we
need
to
do
to
keep.
A
C
A
Yeah,
so
I've
prefixed
all
of
the
issues
in
the
document
with
where
I
think
the
work
needs
to
happen
right.
Everything
that
is
kind
of
like
in
our
wheelhouse
should
be
easy
enough
for,
for
the
both
of
you
to
pick
up,
I
would
definitely
involve
people
from
frameworks,
igor
and
so
on,
when
we
try
to
spin
up
a
new
instance,
cool
everything
that
is
marked
with
gitlab
rails
and
so
on.
You
can
tackle,
but
then
you're
going
to.
A
The
the
the
review
process
in
gitlab
get
lab
work,
gitlab,
that's
yeah,
so
that
kind
of
all
depends
on
how
much
do
we
need
to
know
about
the
data
that
we're
going
to
be
putting
in
this
new
cache
to
be
able
to
start
preparing
it.
C
What
about
the
the
apart
from
this
epic?
The
the
pressure
relief
that
we're
trying
to
get
from
from
the
other
issues?
The
improve
efficiency
of
discussion?
Caching,
yeah.
B
A
B
B
C
Then
an
issue
for
us
to
yeah
exactly
to
track
it,
and
we
will
probably.
A
C
C
B
B
C
B
C
B
A
C
A
A
C
C
So
so
I
guess
I
wanted
to
ask
what
what,
if
anything,
should
we
do
in
your
absence
to
keep
those
moving
just
to
keep
the
momentum
on
it.
A
A
Stephanie,
maybe
you
can
find
that
merge,
request
and
link
it
from
the
thing
that
you
are
going
to
create
it's
linked
from
one
of
the
issues.
That
is,
I
think,
igor
other
igor
igor
d,
created
that
so
then
we
can
already
have
a
look
at
those
metrics.
I
think
they
don't
include
sizes.
Yet,
though,
but
yeah.
A
C
No
yeah,
I
I
can't
think
of
anything
at
the
moment.
A
C
Yes,
just
because
I'm
not
super
familiar
with
that,
with
that
framework,
can
you
can
you
very
briefly
go
over
the
the
e-tag
mechanism?
Is
this
what's
what's
the
so
this
is
client-side
storage?
Is
there
is
there
do
we
need
to
worry
about
like
an
upper
bound
on
on
storage,
size
limits
for
the
client
side.
A
Don't
think
so
it's
I
don't
think
so!
It's
the
browser
takes
care
of
that
like
if
there's
not
enough
space
anymore,
it
will
evict
and
we'll
need
to
re-render
that,
yes,.
B
A
C
A
Makes
sense
yeah,
that's
about
it.
Okay,.
C
Okay,
fantastic,
I
was
just
trying
to
think
through
potential
side
effects
like
we
talked
about.
You
know
where,
avoiding
somewhere
by
caching,
these
items,
if,
if,
if
for
whatever
reason
the
client
refuses
to
to
cache
the
item,
then
this
would
implicitly
increase
workload
kind
of
silently
from
our
perspective
on
some
other
parts
of
the
system.
So
I
wasn't.
A
Sure
how
to
address
that
the
groups
that
are
working
on
these
will
feature
flag
them
that
I'm
sure,
and
they
should
be
looking
at
the
right
logs
to
look
at
the
request.
Duration.
But
I
expect
that
request.
Duration
will
be
much
better
because
most
of
the
requests
will
turn
into
304s
instead
of
yeah
data
over
the
wire.
C
C
That
makes
sense
yeah.
No,
this
is
wonderful,
though
this
is
going
to
be
kind
of.
I
mean
this
sounds
like
it's
going
to
be
a
performance
improvement
from
the
user's
perspective
as
well.
As
you
know,
our
system
doing
less.
It's
we're
moving
the
cache
closer
to
the
client.
I
mean,
as
close
as
it
can
be
to
the
client,
so.
A
Yeah
yeah
there
there's
still
an
argument
to
be
made
for
having
both
in
some
cases,
though
so,
but
we
will
revisit
that
once
yeah
yeah.
A
A
C
A
B
A
Yeah,
that's
what
it
sounds
like
and
figure
out
how
to
size
how
to
size.
It
correctly
like
I've
mentioned
metrics
like
right,
discuss
with
each
other.
If
what
I'm
suggesting
makes
sense
and
if
not
wreck
it
and
put
something
corrected,
sure:
okay,
cool
I'll,
stop
the
recording.