►
From YouTube: GitLab 14.2 Kickoff - Enablement:Memory
Description
Kickoff for the 14.2 release for the Memory team.
Planning issue: https://gitlab.com/gitlab-org/memory-team/team-tasks/-/issues/96
A
A
So
the
first
thing
to
note
is
that
it's
summertime
and
a
couple
of
our
team
members
are
on
pto
this
release.
So
we
have
a
slightly
reduced
capacity
for
this
milestone,
sort
of
focus
on
two
main
items,
so
we
are
still
in
the
process
of
shifting
sidekiq
workers
from
our
primary
database
instance
to
database
replicas.
A
A
The
second
item
that
we
started
in
14.1
that
we
will
continue
in
14.2
is
to
update
ruby
to
version
3.0,
so
this
has
a
bunch
of
performance
implications
and
overall
improvements
to
the
ruby
language.
You
can
read
about
the
release
here,
so
this
is
in
process.
It
involves
a
lot
of
like
updating
of
dependencies
and
making
sure
that
we
fully
support
the
latest
and
greatest
ruby
version,
so
this
will
continue
in
in
14.2,
and
these
are
the
two
main
things
that
we
are
going
to
continue
to
drive
forward
in
the
upcoming
release.
A
There
are
two
more
items
that
we
would
like
to
investigate
a
little
bit
further,
but
that
we
may
not
get
to
given
our
capacity
constraints,
so
the
first
one
has
to
do
with
configurations
of
the
puma
per
worker
memory
allocation,
and
so
this
is
about
our
web
server,
and
so
there
are
some
concerns
regarding
the
memory
limits
that
we
set
and
we
will
investigate
this
a
little
bit
further
now.
Lastly,
you.
A
This
is
a
longer
term
project
that
we
may
be
maybe
working
on.
So
one
thing
that
the
that
we
would
like
to
understand
a
little
bit
better
is
how
critical
user
journeys
are
impacted
by
performance
bottlenecks.
So,
rather
than
focusing
only
on
sort
of
holistic
improvements
of
performance,
we
would
like
to
measure
specifically
if
some
critical
user
journeys
that
are
sometimes
yet
to
be
defined.
For
example,
let's
say
a
merge
request
review
if
there
are
sort
of
rate
limiting
steps
in
that
in
that
process.
So
an
example
could
be
you
open
a
merge
request?
A
A
We
still
need
to
define
an
mdc
and
a
proof
of
concept,
but
it
would
be
amazing
to
be
able
to
pinpoint
specific
pages
and
specific
requests
that
are
taking
a
long
time
that
then
ultimately
make
things
slow,
and
we
know
that
perceived
slowness
is
a
key
concern
at
gitlab.
So
we'll
start
thinking
about
this,
but
don't
expect
any
implementation
in
14.2
and
that's
it
from
the
memory
team
for
14.2.