►
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
Hello,
everybody,
my
name
is
Roger
and
I
am
here
for
16.0's
application.
Performance
Group
planning
this
16.0
cycle.
Our
team
expects
to
be
operating
at
full
capacity,
because
Nikola
will
be
back
from
paternity
leave.
He's
been
away
for
two
months
and
I
think
we'll
plan
for
some
time
for
him
to
catch
up,
but
we're
pretty
excited
to
have
everybody
back
our
general
top
priorities
for
160.
Our
team
is
continuing
to
pursue
opportunities
to
build
domain
knowledge
around
real-time
systems
and
the
foundational
Technologies.
A
We
believe
these
efforts
will
help
us
level
up
as
a
team
and
position
us
to
eventually
advise
on
some
more
complex
questionings
of
Designing
and
operating
High
complexity.
Event
architectures
with
graphql.
Our
top
priority
here
P0,
is
to
improve
real-time
observability.
Recently,
gitlab
has
suffered
from
some
noticeably
noticeable
availability
incidents,
leading
to
a
hard
production
change
lock
and
we
believe
observability
to
be
a
significant
Foundation
towards
building
and
shipping
with
confidence
and
to
be
able
to
iterate
quickly.
Improving
real-time
observability
also
aligns
with
our
team's
intent
to
provide
in-context
monitoring
via
the
performance
bar.
A
Our
next
priority
after
that
is
to
improve
graphql
throughput
as
real-time
use
cases
spread
across
gitlab.
We
will
be
spending
sending
more
and
more
data
via
real-time
rails
and
these
real-time
elements
in
turn,
increase
in
complexity.
The
graphql
capacity
limits
become
a
bottleneck.
Improving
graphql
throughput
is
a
targeted
focus
of
our
team's
overall
rate
limiting
Charter.
This
will
also
support
our
overall
intent
to
improve
the
performance
and
scalability
of
our
real-time
systems
and
in
turn
this
will
then
enable
stage
groups
to
send
fewer
real-time
payloads,
each
with
more
data.
A
Our
last
priority
here
is
just
a
few
Tech
debt
cleanup
items
several
Milestones
ago.
Application
performance
was
the
memory
team
and,
as
part
of
that
Charter,
we
Consolidated
a
lot
of
memory
killer
systems
across
gitlab
we've
been
monitoring
to
ensure
there's
been
no
adverse
impact
from
this
effort
and
we'll
be
cleaning
up
some
of
those
areas.
In
16.0
longer
term,
we
expect
the
above
items
to
continue
and
in
no
particular
order.