►
From YouTube: Gitlab 13.12 Kickoff - Create:Gitaly
Description
Planning Issue - https://gitlab.com/gitlab-org/create-stage/-/issues/12838
A
A
They
tried
to
do
some
explorations
in
the
backup,
speed
using
concurrency
and
it
didn't
go
so
well,
so
we're
stepping
back
we're
going
to
iterate
again-
and
this
is
one
of
those
situations
where
we
found
another
path
forward,
we're
going
to
go
ahead
and
work
on
a
different
approach
and
once
it's
working
once
this
is
working
and
we
have
a
satisfactory
solution.
We'll
then
continue
to
iterate
to
make
it
an
even
better
solution.
So
I'm
really
proud
of
the
team
for
their
work
into
this.
You
know
you
never
learn
things.
A
If
you
don't
try
and
we
we
tried,
and
we
found
some
issues.
So
that's
fantastic
and
I
applaud
the
team
for
their
efforts.
The
other
thing
that
we
are
trying
to
do
is
improve
performance
surrounding
commit
graphs.
There's
a
lot
of
areas
where
commit
graphs
will
help
performance
specifically
when
we
start
using
the
bloom
filter
opportunities
that
are
part
of
that.
What
we
have
seen
is
a
significant
improvement
by
using
commit
graphs.
A
You
can
see
the
timing
with
commit
graphs
is
substantially
faster,
so
we're
looking
to
areas
where
we
could
potentially
improve
performance
for
our
users
by
leveraging
commit
graphs.
Now
they
come
with
some
downsides:
we're
looking
to
mitigate
on
those
and
we're
sort
of
trying
to
do
this
in
iterative
manner.
So
over
the
next
few
releases,
you'll
see,
let's
continue
to
iterate
through
commit
graphs
and
bloom
filters
and
to
make
the
experience
as
good
as
possible
for
everyone.
A
The
other
thing
that
we're
focused
on
as
an
initiative
is
to
roll
out
repository
specific
primaries.
Now
this
almost
rolled
out
there
were
some
issues,
so
we
had
to
pull
it
back
and
again
evaluate
where
we're
going
with
it,
make
a
few
updates
and
we're
hoping
to
get
this
rolled
out
relatively
soon.
There's
nothing
major.
We
don't
believe
that's
going
to
cause
us
issues.
This
is
really
important
for
a
few
reasons.
One.
A
This
allows
us
to
have
a
primary
getaly
cluster
node
per
repository
instead
of
just
for
the
general
cluster,
and
this
will
open
up
a
lot
of
opportunities
for
variable
replication
factor
being
different
among
different
repositories,
and
things
like
that.
So
this
is
really
important
to
our
road
map.
The
team
has
been
working
really
hard
and
we're
very
close,
so
I'm
excited
to
see
this
roll
out
and
in
addition,
it's
going
to
actually
help
us
because
it's
going
to
reduce
our
complexity
quite
significantly.
A
Right
now
we're
maintaining
two
code
stacks
and
we
want
to
kind
of
help
eliminate
performance
problems
by
focusing
on
one
code
stack.
So
that's
really
important.
Ideally
we're
looking
to
migrate
users
to
repository
specific
primaries
in
14-0.
That
is
our
plan.
Currently,
if
there's
any
changes
to
that,
we
will
update
the
direction
page
to
show
that.
A
Finally,
you
see
there's
a
few
opportunities
here
for
performance.
One
of
the
big
things
is:
we
want
to
get
the
gili
app
decks
into
usage
ping.
So
it's
more
easy
to
monitor.
This
is
just
great
from
a
product's
perspective.
We
can
see
exactly
what
our
aptx
looks
like.
We
can
monitor
it
closely
and
we
can
really
measure
ourselves
against
that
to
focus
the
team
around
this.
The
shared
goal,
so
that's
exciting
and
again
we're
putting
some
bug
fixes
in
there
too
that
have
come
up
over
the
past
month.