►
From YouTube: GitLab Architecture 101 for Support Engineers
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
A
That
make
up
kidnap
that
makeup
and
g-lab
environment
work
and
how
they
kind
of
work
together.
I
wouldn't
be
covering
all
the
components
as
well
just
the
core
components,
so
I
probably
will
not
be
talking
about
things
like
that
pages
or
registry,
or
some
of
the
other
ancillary
services
that
we
do
have
so
before
I
really
get
into
it.
I
just
wanted
to
say
that
my
explanations
actually
based
on
my
experience
as
a
developer
of
rails
applications
and
deploying
rails
applications.
A
I
have
never
taken
a
computer
science
course
of
any
thought.
So
in
many
cases
my
explanations
will
be
based
on
just
my
the
way
I
kind
of
see
things.
They
may
not
actually
be
technically
accurate
explanations,
so
my
suggestion
is:
do
your
own
reading
and
if
anyone
does
want
to
chime
in
with
a
more
technically
accurate
explanation,
please
feel
free
to
do
so.
This,
hopefully,
will
be
a
bit
more
interactive.
A
A
A
A
Right
so
rails
itself,
it's
actually
that's
the
framework.
It
is
sort
of
like
a.
It
is
a
framework
that
takes
on
requests
web
requests
and
gives
a
response,
but
on
its
own
it's
actually
not
the
web
server.
The
web
server
itself
is
actually
puma.
In
current
gitlab
environments,
we
used
to
use
unicon,
but
now
we
use
puma.
A
A
A
A
A
So
what
happens
is
that
essentially
a
web
request
comes
in
puma
would
serve
it
to
basically
the
first
rack
in
the
rec
stack
and
then
basically
goes
down
and
it
finally
goes
to
rails,
and
then
you
get
a
response.
So
generally
that's
I
mean
it
probably
isn't
the
best
explanation,
but
that's
how
it's
worked.
That's
how
this
works.
This
is
also
why,
if
rack,
timeout
or
wrecked
attack,
which
we
use
for
rate
trotting,
if
they
actually
reject
a.
A
C
Sorry,
I
have
one
waymink
sure
you
said
that
rack.
Is
this
ruby
app,
that's
like
a
middleware
between
puma
and
rails
and
if
there's
some
sort
of
a
rejection
of
the
request
prior
to
getting
to
rails,
you
know
that'll
happen
outside
of
rails,
but
if
racks
of
ruby
app
is
that
yeah?
Is
that
using
the
same
like
ruby,
runtime
or
is
it
different?
Is
it
separate.
A
I
don't
know
the
answer
to
that.
Actually,
so
all
rec
apps
are
all
middleware
and
in
fact,
rails
itself
is
a
racket
as
well.
So
it's
just
that
real
happens
to
sit
at
the
very
bottom
of
that
stack.
If
that
makes
it
if
that
makes
sense,
so
rack
timeout
sits
on
top
of
that.
Another
good
example
of
a
rack
app,
which
I
think
you
might
be
familiar
with,
but
you
might
not
have
realized
that
it
actually
is
a
rack
app.
A
It's
actually
only
off,
so
we
use
omniof
to
provide
authentication
processing
for
different
providers
such
as
github.
I
think,
google
as
well
and
samla,
and
a
bunch
of
other
stuff,
so
how
it
actually
works
in
this
case
is
that
it
actually
receives
the
authentication
callback
from
these
external
providers.
It
then
kind
of
takes
the
information
that
we
need,
which
is
generally
the
authentication
token
and
the
username.
I
think,
and
adds
it
to
the
request
environment
variable.
A
So
this
is
how
rails
kind
of
knows
in
in
a
standardized
form
how
to
kind
of
interact
with
those
things.
So
sorry,
I
think
that
was
a
bit
of
digression,
but
does
it
have
one
help
you
to
understand
kind
of
how
it
works?
Yes,
that
was
awesome.
Thank
you,
okay,
but
yes,
I
I
don't
actually
know
if
it's
the
same
ruby
environment.
I
think
it
is
because
I
think.
A
A
A
A
B
A
I
actually
don't
know
the
technical
details
of
that,
but
my
understanding
is
that
rec
kind
of
takes
a
rap
incoming
http
request
right
and
then
transform
it
into
sort
of
like
a
standardized
format,
so
that
any
other
person
that
wants
wants
to
write
a
reg,
middleware
or
rack
app
has
a
consistent
interface
that
they
can
work
with.
So
they
don't
have
to
worry
about.
A
Like
hey,
you
know,
if
you're
sending
in
this
request,
you
know
what
are
the
haters
that
you're
going
to
send
use,
so
it
kind
of
kind
of
takes
all
of
that,
and
then
it
kind
of
transforms
the
request
into
something
that
is
kind
of
like
a
standard
interface,
so
that
you
know
anyone
that
wants
to
write
write
a
rack
up.
They
can
do
so
without
having
to
worry
about.
A
Oh
you
know,
I
have
to
think
about
so
many
other
ways
that
you
know
you
might
actually
end
up
having
a
http
request,
it's
kind
of
kind
of
like
xml
it
for
for
people
that
you
know
have
worked
with
xml.
There
is
a
standard
for
xml.
Usually
there
is
a
document
documented
standard.
In
terms
of
you
know
what
keys
to
use
what
attributes
to
use,
but
of
course
no
one
follows
that
everyone
has
their
own
xml
standard
and
that
that
is
a
pain.
A
A
B
A
A
A
It
turns
out
that
my
understanding
is
wrong.
It
turns
out
that
actually,
ruby
does
have
a
pretty
good
garbage
collection
process.
It's
just
that
for
web
applications
like
rails
memory,
allocation
happens
when
client
clients
hit
endpoints,
and
the
frequency
of
a
web
of
endpoints
being
hit
in
a
web.
Application
is
high
enough
that
ruby
actually
ends
up
allocating
more
memory
than
it
frees
up.
So
essentially,
garbage
collection
happens,
slower
than
requests
come
in,
so
memory
allocation
increases
over
time.
A
I
guess
within
the
known
range,
because
the
number,
the
amount
of
memory
that
a
puma
worker
takes
up
does
affect
the
total
number
of
workers
you
have.
I
mean
you
can't
exceed
the
total
number
of
ram
on
your
system,
for
example.
So
so
that's
one
reason
why
you
see
that
all
the
time-
and
it's
not
a
sign
of
the
puma
itself
being
unhealthy
if
it
happens,
something
like
every
20
seconds
to
30
seconds
or
even
40
to
50
seconds.
B
A
B
So
that's
that's
what
I
was
about
to
add.
Just
there
was
one
one
function
of
it,
so
having
puma
worker
being
killed
sounds
bad,
but
it's
not
necessarily
bad
from
from
the
stability
standpoint,
because
the
whole
point
of
having
this
is
to
actually
maintain
the
memory
right
and
I
think
yeah.
There
was
another
thing
about
this:
this
was
the
the
worker
kill
actually
configured
to.
B
We
call
it
recycle
we
get
recycled
on
a
daily
basis,
that's
just
part
of
the
default
configuration
and,
I
think
yeah.
Basically,
it's
the
same
thing
just
to
maintain
the
memory
usage
of
the
rails.
Anyway,
I
thought
it
was
just
something
that
if
you
see
that
it
got
restarted,
it
doesn't
mean
it's
necessarily
bad.
I
think
the
frequency
causes
issues
yeah.
A
So
one
other
thing
that
I
should
mention
is
that
when
I
say
the
puma
worker
gets
killed,
it
always
gets
restarted
because
if
you
know
say
if
we
define
in
the
gilab
rb
file,
we
want,
we
always
want
to
have
six
workers.
For
example,
there
will
always
be
six
workers,
so
even
if
we
kill
one,
the
puma
master
process
essentially
will
try
to
restart
it
such
that
there
will
be
six
processes.
A
A
C
I've
seen
that
I've
had
a
couple
of
tickets
involved
where
puma
worker
killer
was
killing
the
puma
workers
in
the
middle
of
requests
and
the
users
were
getting
502s,
but
sometimes
depending
on
the
request.
They
may
not
receive
that,
but
they
might
maybe
see
request
fail
or
some
other
functionality
not
working
as
expected,
yeah
and
usually
in
those
times
we
would,
you
know,
increase
the
worker
per
you
know
per
worker
memory
to
avoid
that
from
happening.
C
A
The
the
real
test
of
whether
your
workers
are
being
killed
too
frequently
is
actually
yes,
you
know
are
too
many
requests
being
cut
off
in
the
middle
of
something
happening,
so
this
is
actually
a
statistical
game,
basically,
because
if
your
workers
are
restarting
too
frequently,
what
will
happen
is
that
you
get
a
whole
bunch
of
requests
that
there'll
be
more
requests.
Essentially
they
get
cut
off
mid
flight
and
then
that
creates
a
poor
user
experience
so
20
to
30
seconds.
A
It's
probably
a
good
guideline
as
to
what's
okay,
but
yes,
you
know,
if
you
do
hear
customers
reporting
that
that
they
are
mysterious,
500s
or
502s
all
the
time
yeah.
That
probably
means
that
there's
too
little
memory
allocated
to
each
puma
worker
and
they
are
restarting
too
frequently
causing
there
to
be
too
many
opportunities
where
connections
get
cut
off
needed
like
so.
Yes,
that
is.
That
is
the
better
way
to
look
at
it.
B
B
B
Yeah,
so
so
this
is
the
thing
my
understanding
of
part
of
this
is
also
because,
if
the
code
itself
actually
have
some
runaway
process
that
I
don't
know
not
garbage
collected
properly,
this
rails
timeout
actually
guards
against
that.
But
that's
my
understanding
of
why
it
doesn't
actually
have
a
graceful
termination.
B
A
I'm
not
fully
clear
about
it
as
well,
but
I
think
I
did
read
somewhere
that
it
is
extremely
difficult
for
ruby
applications
to
know
introspectively
how
much
memory
is
actually
consuming.
So
the
way
we
keep
program
workers
is
actually
a
separate
outside
of
braille
sort
of
process,
so
it
doesn't
actually
know
what
rails
is
doing.
It
just
sees
that
the
promo
worker
is
beyond
the
range
of
acceptable
memory
usage
and
you
just
use
it.
You
know,
regardless
of
what's
going
on
with
that
worker
process
at
that
point
in
time.
A
A
Cool
okay,
thank
you
yeah.
I
just
want
to
touch
on
some
of
the
scaling
triggers
that
they
might
see
for
puma
before
we
move
on
to
the
rest
of
the
gitlab
components.
So
the
scaling
triggers
for
puma
are
basically
cpu.
You
need
cpu
to
run
the
workers,
it's
actually
less
than
unicorn.
If
I
phone
with
unicorn
unicorn
is
basically
one
unicorn
worker
per
dcpu,
whereas
I
think
puma
is
invented.
So
that's
a
bit
more
play
there,
but
you
know
cpus
are
still
something
you
might
want
to
think
about.
A
The
other
scaling
trigger
that
we
have
is
ram.
You
know
if
we
have
four
workers
taking
up
adding
1.2
gigs
of
ram
each,
and
you
only
have
four
gigs
of
ram
yeah.
That's
no,
but
that's
not
going
to
fly
so
jealous
getting
trigger
is
ram.
If
you
are
running
out
of
memory
to
run
more
workers,
then
yes,
you
need
more
ram.
A
Yes,
you
could
do
that,
so
you
know.
If
you
want
to
maintain
the
amount
of
ram,
then
you
need
more
machines,
but
I
think
that's
a
better
scope
of
this
environment
session
there's
also
one
other
scaling
trigger
to
think
about.
Although
it's
more
of
a
performance
problem
than
a
real
scaling
trigger
in
a
very
extreme
cases,
you
can
actually
run
out
of
file
descriptors
for
rails
applications.
The
reason
behind
this
is
that
rails
and
ruby
I
mean
rails
in
particular-
is
dynamically
compiled.
A
So
essentially,
whenever
you
run
a
rails
application,
it
basically
opens
tons
and
tons
and
tons
of
files.
So
in
very
rare
and
extreme
cases.
We
have
seen
this
a
few
times
before.
Customers
actually
report
that
the
underlying
os
reports
that
you
can
no
longer
open
new
files-
and
it
just
refuses
to
do
anything
so
that's
something
to
think
about
as
well.
In
case
you
to
encounter
this
mysterious
thing
where
mysterious
errors
are
happening,
but
you
don't
really
know
why
it
could
be
worth
checking
there.
So
yeah.
C
You
can
also
configure
you
know,
apart
from
the
number
of
workers,
and
the
number
of
amount
of
ram
per
worker
to
consume
is
the
threads
per
worker
and
a
lot
of
the
time.
You
know
you
should
keep
that
default,
but
harsh
and
I
had
an
interesting
problem
where
our
customers,
you
know
premiere,
it
wasn't
starting
up.
B
B
B
A
B
A
That
that
that's
exactly
the
reason
why
we
want
to
have
a
60
second
timeout
per
request.
So
if
you
have
many,
many
many
actually
don't
need
that.
Many
at
all.
We
will
talk
about
this
when
we
talk
about
italy,
which
is
interesting,
but
you
know
if
we
have
two
or
three
requests
that
take.
Let's
say
two
minutes
each
and
you
have
four
of
those
and
you
only
have
four
workers
that
are
serving
requests.
A
A
So
yes,
so
this
is
why
I
believe
in
our
documentation.
In
the
past
we
used
to
put
in
things
like
you
know,
you
can
actually
increase
the
timeout,
but
be
careful.
They
don't
actually
tell
you
why
you
have
to
be
careful.
So
this
is
the
reason
why
you
have
you
have
to
be
aware
that
you
know
if
too
many
long-running
requests
happen.
A
A
Okay,
so
I
I
specifically
want
to
talk
about
the
timeout,
because
this
is
actually
the
key
reason
why
we
have
so
many
other
components.
So
I
guess
the
next
question
to
us
right
is:
if
we
have
a
60
second
timeout
on
puma
request,
then
how
do
we
actually
run
processes
or
run
transformations
that
actually
take
more
than
60
seconds?
A
A
So
yes,
from
from
from
a
web
development
perspective,
there
are
actually
a
few
reasons
you
want
to
run
psychic
beyond.
Just
you
know,
having
beyond
just
jobs
that
might
take
longer
than
60
seconds.
So
a
good
example
is
when
you
actually
need
to
async
something
where
it
doesn't
make
sense
to
have
it
blocked
a
synchronous
transaction.
So
a
good
example
is
say:
if
you
create
a
comment
in
a
support
team
meta
issue
and
on
that
support,
team
meta
issue,
there
are,
I
think,
30
other
support
engineers
who
have
also
commented.
A
Can
you
imagine
if
you
kind
of
post
a
comment,
and
then
you
have
to
wait
for
the
smtp
server
to
send
30
emails
to
notify
everyone.
It
will
take
forever.
So
what
happens
is
that
we
will
just
actually
send
the
comment
first
and
then
we'll
send
a
background
drop
to
psychic
or
30
background
jobs
decide
actually
to
send
those
emails.
A
Something
else
you
might.
You
might
have
seen
with
background
jobs
is
also
with
payment
processing.
You
might
have
encountered
before
where
your
order
actually
is
confirmed,
and
then,
sometime
later
you
get
a
notification
saying
that
your
payment
method
has
failed.
That's
because
some
e-commerce
platforms,
they
essentially
want
your
business,
so
they
confirm
your
order
first
and
then
they
process
your
payment
in
the
background,
because
sometimes
payment
processing
can
take
up
to
two
minutes.
A
A
A
C
A
A
A
A
A
And
again,
I
don't
know
if
I'm
using
the
correct
flowchart
symbols
for
this.
For
me,
if
I'm
mangling
it,
but
yes,
so
the
queue,
the
background
queue
for
sidekick,
it's
actually
stored
in
redis.
So
a
quick
introduction
to
redis
redis
is
a
key
value
store.
That
is
very,
very,
very,
very
fast
and
the
reason
why
it's
so
fast
is
that
the
entire
of
its
working
memory
is
stored
in
ram.
Essentially
so
the
scaling
trigger
for
reddish
is
just
the
amount
of
ram
you
have
available
to
redis.
A
If
you
are,
I
would
be
very
surprised
if
you
run
out
of
ram
with
redis,
unless
you
you,
you
are,
you
know
provisioning
some
very
set
amount
like
one
gig
or
less
to
register,
but
yeah
it.
It
scales
at
two
as
much
ram
available
as
it
does
so
how
how
how
the
web
rails
actually
sends
jobs
to
the
psychic
rails
is
that
it
actually
does
this.
A
It
essentially
sends
a
request
to
redis
saying
that
you
know
I
want
to
store
this
data,
essentially
this
one.
So
I
want
to
send
the
worker
class
with
the
arguments
into
one
of
the
lists.
Basically,
so
one
one
more
thing
is
that
the
reddit
stores
keys
values
in
list,
so
each
list
essentially
represents
a
queue
in
in
in
psychic.
A
A
A
B
A
A
Yes,
this
is
actually
basically
taking
a
result
storing
in
cash
so
that
the
next
time
you
access
it,
you
no
longer
have
to
run
the
calculations
anymore.
You
just
get
the
result
directly,
some
common
things
that
we
saw
in
cash,
not
just
things
that
require
a
lot
of
processing,
but
also
things
that
are
very
commonly
retrieved
and
it's
much
faster
to
retrieve
this
from
redis
than
it
is
from
the
database.
So
one
common
example
about
for
this
is
actually
application
settings
in
gitlab.
B
B
A
I
was
gonna
say
what
I
know
about
reddit
is
that
so
reddit
stores
everything
in
memory,
but
it
still
needs
a
way
to
persist
this
between
events,
where
you
restart
your
server
or
you
know
you
lose
power
to
your
server.
So
as
far
as
I
know,
in
the
context
of
reddit
persistence
means
that
you
know
every.
A
I
can't
remember
how
often
it
is,
but
every
so
often
it
does
actually
persist
all
of
its
in-memory
values
to
the
disk,
so
that
the
next
time
red
is
reboots,
you
can
actually
repopulate
the
the
what's
in
memory,
so
I'm
I'm
not
sure.
Actually
what
you
mean
by
you
know.
We
can
separate
the
regis
persistence
from
the
various
values
in
memory.
B
I
literally
just
find
out
like
half
an
hour
before
this
call
that
we
can
actually
separate
ready's
cash
and
ready's
persistence,
especially
in
the
10k
architecture.
Above,
so
that's
why
I
was
like
wait.
This
is
a
new
thing
for
me,
so
I've
started
to
kind
of
like
think
about
it
in
a
different
way,
because
I
always
thought
redis
is
a
very.
B
B
B
A
No,
no
worries
that
actually
gives
me
something
to
look
more
into
as
well,
because
there
are
many
different
ways
to
do.
Redis,
like
you
know
it
stores
things
in
lists.
So
in
theory
you
could
have
multiple
radishes
each
with
its
own
different
set
of
lists,
and
this
is
this
is
kind
of
what
we
do
with
psyche
as
well.
If
you
kind
of
want
different
workers
to
process
different
cues,
we
we
have
them
in
separate
lists,
but
yeah.
I
don't
go
over
that.
A
C
A
Yes,
that's
right,
so
so
in
in
this
flow
here,
whatever
what
happens
is
that
the
web
rails
will
say?
Okay,
you
know
based
off
this
request.
I
want
to
run
this
worker
class
with
these
arguments,
so
it
essentially
stores
these
arguments
into
radis
and
then
later
on,
psychic,
when
a
psychic
worker
is
free,
it
will
pull
reddish
for
the
next
job
in
in
the
queue
essentially
and
it
sees
worker
class,
and
these
are
the
arguments,
so
it
has
the
same
copy
of
rails
that
the
web
rails
does.
A
A
A
A
A
Right
so
the
idea
behind
this
tool
is
that
and
keep
in
mind
that,
in
order
to
serve
new
requests,
postgres
will
always
itself
and
that
to
kind
of
basically
start
up,
a
new
postgres
process
is
a
very
expensive
one.
So
the
reason
why
we
have
a
pool
with
multiple
connections
in
that
pool,
hence
the
connection
tool,
is
that
once
one
database
connection
is
done,
it
doesn't
actually
close
that
connection.
A
It
maintains
the
connection
pool
so
that
if
there's
a
second
connection,
you
can
actually
reuse
an
existing
connection,
so
you
don't
have
to
keep
postgresql
all
right.
The
postgres
doesn't
have
to
keep
itself
in
order
to
serve
new
database
requests.
So
this
is.
This
is
basically
a
performance,
optimization
technique,
and
this
is
why
you
might
hear
about
things
like
database
pooling
or
connection
pooling.
So
this
is.
This
is
a
useful
concept
to
understand
that
rails.
Actually,
does
it
natively
so
psychic?
Does
it
puma?
Does
it
or
rather
rails?
A
So
how
this
normally
works
is
that
you
define,
like
you,
want
your
connection,
pool
to
be
eight
essentially
or
for
whatever
it
is,
and
then
it
will
actually
create
new
connections
to
the
database
until
you
reach
the
maximum
number
of
connections
and
then
it
will
stop
creating
new
database
requests
so
on
the
postgres
end,
it
doesn't
actually
know
any
of
this.
It
just
knows
that
I
have
incoming
requests.
A
D
A
D
A
D
A
C
A
A
Yeah
yeah,
so
so
the
postgres
server
doesn't
care
about
the
connection
pooling
it
just
knows
that
I
have
an
incoming
process.
I
will
for
myself
to
to
meet
that
process.
Sorry
incoming
connection,
I
will
force
myself
to
meet
that
connection.
If
I
don't
have
enough,
if
I
don't
currently
have
enough
processes
to
to
deal
with
it
so
yeah
connection
pooling,
is
always
kind
of
inside.
A
B
A
A
A
A
A
Okay,
if
not,
then
I
I
do
want
to
cover
a
few
more
things
about
postgres,
not
specifically
to
the
service
itself,
but
to
more
how
we
use
it.
So
each
postgres
server
can
actually
have
multiple
databases,
the
one
that
we
use
for
gitlab.
It's
called.
If
I'm
not
wrong,
get
that's
not
a
letter.
G
is
get
lab.
A
Yes,
the
database,
which
we
use
is
hq
production
for
kid
lab
something
interesting
to
note
here.
The
reason
why
it's
called
hq
production
is
because
I'm
guessing
when,
at
the
very
beginning
of
gitlab,
when
we
created
the
gitlab
rails
application,
someone
ran
this
command
rails.
New
gitlab
hq
because
yeah
this
actually
is
a
rails
convention
where
the
database,
this
is
the
app
name,
and
then
this
is
the
environment
that
the
database
is
meant
to
be
in.
A
A
A
So
one
thing
to
note
here
is
that,
if
I'm,
if
I
remember
correctly,
the
gitlab
rate
backup
task
actually
only
backs
up
this
database,
it
doesn't
actually
back
up
the
metamodes
database
if
I'm
not
wrong,
but
I
could
be
wrong
as
well.
You
know,
but
yeah,
that's
always
something
to
look
out
for
the
second
thing
about
this.
To
note
is.
A
Yes,
I'll
cover
this
as
well,
so
what
happens
in
fortress
kind
of
stays
in
progress,
what
happens
in
real
estate
in
rails?
So
whenever
we
update
a
rails
application,
we
will
need
to
figure
out
a
way
to
tell
the
database
to
update
its
schema
or
its
data
structure
in
order
to
meet
the
needs
of
the
software
itself,
and
that's
why
we
have
database
migrations,
so
database
migration
is
essentially
a
way
for
rails
to
define.
A
A
A
A
C
B
C
A
So,
yes,
that
that
that
is
exactly
how
what
it
does
so.
One
thing
to
note
here
is
that
italy
can't
actually
run
any
arbitrary
gate
commands.
It
has
to
run
commands
based
on
remote,
procedural
cores
or
grpcs,
which
have
to
be
predefined
by
developers.
So,
yes,
italy
can't
simply
run
anything
it
wishes.
It
can
only
run
what
our
developers
has.
A
A
A
Yeah
14
day
line
exit.
This
is
actually
application
error,
so
there
actually
are
three
tutorial
timeouts
defined
with
this
there's
a
fast
timeout,
there's
a
medium
timeout
and
there's
a
slow
timeout
and
then
there's
an
overall
timeout
the
overall
time
out.
If
I'm
not
wrong,
is
set
to
57
seconds,
which
is
95
of
the
puma
timeout
and
then
the
others
are
set
at
some
value,
which
I
can't
remember
so
again
this.
A
So
and
someone
correct
me
if
I'm
wrong
here,
if
I
remember
correctly,
the
timeout
actually
happens
on
the
puma
side.
So
when
you
see
daylight
exceeded,
it
actually
happens
on
puma,
but
italy
in
the
background,
still
runs
the
command.
He
doesn't
care
that
there's
a
timeline.
It
doesn't,
you
know,
do
like
a
queue
of
the
process.
It
just
continues
running
that
git
command
until
it
finishes
so
yeah
you,
you
occasionally
see
this
in
tickets
as
well.
A
Where
people
ask
like
hey,
you
know
this
time
is
happening,
but
the
italy
server
still
seems
busy
and
he's
still,
you
know
churning
something.
No
other.
That's
exactly
why
there's
some
gain
operation
that
is
continuing
to
run,
even
though
puma
says
you
know
I'm
done.
I
don't
want
to
continue
with
this
guitary
operation
anymore.
C
Sometimes
I
see
in
the
grpc
requests
it
has
like
a
start
time
and
then
it
has
a
deadline
start
and
a
deadline
end
time.
So
is
it
that
gitzly's
already
aware
of
the
deadline?
That's
been
set
and
does
it
proactively
fail
if
the
duration's
above
that
or
does
it,
as
you
say,
just
keep
going,
but
you
know
that
the
deadline
has
already
exceeded
and
already
been
enforced
by
nginx
or
something.
A
B
C
Yeah,
I'm
not
sure
I
mean
it's
just
something
that
I
observed
and
sometimes
I'd
see
correlations
between
the
deadline
and,
and
you
know
the
end
time
of
the
operation
but
yeah.
I
don't
know
for
certain
if
that
does
happen,
but
it
it
seemed
like
like
it's.
I
don't
know
from
observing
it.
It
looked
like
that
was
the
case,
but
it'd
be
good
to
know.
If
that
is
the
case
or
not.
A
A
Something
else
I
want
to
cover
with
italy
is
so
let's
say
you
have
four
puma
workers
available
to
serve
requests
to
serve
web
requests,
and
you
know
say
if
we
want
to
make
a
request
to
view
a
repository
so
with
four
workers.
How
many
concurrent
repository
requests?
Do
you
think
we
can
do
through
rails.
A
A
Yeah
two
threads:
I
think
it's
more
accurate
for
puma
two
workers
will
be
migrated
for
unicorn.
So
but
yes
it,
each
getally
request
does
take
up
a
bit.
More
can
sorry
can
take
up
a
bit
more
threats
or
workers.
Then
then
you
might
think
it
does
because
they
actually
make
an
internal
request
before
completing
the
original
request.
A
Yeah,
so
so
that's
one
culture
to
know
about
which
it's
really
handy
to
know
as
well,
because
sometimes
customers
who
have
a
relatively
small
omnibus
box
or
sorry,
a
relatively
small
single
box
running
on
the
bus,
can
run
into
things
like
this.
Where
hey
I
trying
to
access
a
much
request
that
my
colleague
is
too
and
now
suddenly,
we
can't
do
anything
yeah.
This
is
why,
although
it's
been
less
common
now,
I
think
more
of
our
customers
are
more
vp
machines,
but
you
never
know
when
this
is
useful
to
see.
A
Mistake
I
think
that
people
do
when
they
first
look
at
gitelli
locks.
Is
they
don't
realize
that
the
utility
locks
are
actually
written
from
the
perspective
of
the
server
itself,
so
post
upload
pack?
If
you
kind
of
look
at
it,
you
might
think
that
this
is
actually
a
git
push,
but
actually
it's
a
git
pool,
because
it's
the
capitalist
server
uploading
data
back
to
the
client
and
same
thing
for
git
receive
pack.
A
A
Okay,
the
last
thing
to
know
about
fog,
italy,
is
that
the
main
performance
driver
is
always
iops.
Kit
has
many
operations
that
involve
many
small
files.
So
if
you
have
ions,
that's
really
low,
like
700
800,
spinning
discs,
essentially
it
probably
will
work,
but
you'll
probably
fall
over
really
quickly
as
well.
If
you
have
av
kit
operations,
you
probably
want
something
more
in
the
range
of
7000
to
8000,
which
is
more
like
a
ssd,
so
yeah,
that's
something
to
take
them
off
as
well.
A
A
A
A
So
both
of
these
are
reverse
properties.
Reverse
properties
are
essentially
web
services
or
web
servers
that
take
a
request
and
then
sends
them
elsewhere,
depending
on
routing
rules.
Usually
this
would
be
hostname
and
portal,
so
gitlab
shell
takes
on
all
ssh
connections.
Generally,
we
are
just
sending
this.
I
think
right
to
keep
the
leaf.
I'm
not
wrong.
A
A
I
don't
know
the
exact
port
numbers
for
many
of
these,
but
yes,
these
are
some
examples
of
where
nginx
can
send
requests
to.
That's
not
actually
the
core
gitlab
components,
but
if
it
does
want
to
send
a
request
to
gitlab
itself,
sorry
the
call
rails
components
it
sends
it
first
to
gitlab
workhorse.
So
this
is
what
costs.
A
So
workhorse
itself
is
actually
another
reverse
proxy.
In
most
cases,
workhorse
will
basically
send
a
request
over
to
rails,
but
the
purpose
of
work
costs
here
and
remember
again
about
the
60
second
timeout.
What
course
is
there
basically
to
intercept
any
long-running
requests,
which
we
don't
necessarily
need
rails
to
actually
do
so.
A
A
A
A
So
yes,
the
whole.
The
whole
point
of
work
course
here
is
to
basically
intercept
any
requests,
which
will
probably
run
longer
than
60
seconds
or
do
not
actually
require
the
rails
application
at
all.
So
this
is
also
an
optimization
type.
Essentially,
you
know
don't
send
requests
to
the
web
server
if
they
don't
need
to
be
served
by
the
web
server.
A
A
A
Okay,
yeah.
I
think
that
that
basically
covers
all
the
topics
I
want
to
talk
about
with
the
architecture,
one
one
I've
covered
the
internals
of
it
and
some
of
the
reasons
why
we
have
them
that
way
and
how
they
kind
of
talk
to
each
other
and
why
they
talk
to
each
other.
That
way,
I've
also
covered
a
bit
about
basically
the
front
doors
to
which
all
requests
are
served,
which
is
the
gitlab
shell
and
nginx
reverse
proxies
and
purely
from
the
developers
perspective.
A
It's
actually
very
interesting
to
see
how
so
many
of
these
components
are
there
just
to
avoid
overburdening
the
rails.
Application
itself,
which
is,
if
you
read
around
people,
have
constantly
consistently
trash
rails
for
being
for
not
being
very
performant,
it's
true,
which
is
why
we
have
all
these.
A
B
I
have
a
comment,
I
think,
so
it's
only
on
sas
right
now
that
gitlab
shell
runs
as
an
sshd
daemon
on
self-managed.
It
still
uses
openssh
and
in
the
authorized
key
file.
So
when
you
log
with
ssh
using
your
ssh
key,
it
runs
a
force
command
which
then
invokes
gitlab
shell
and
then
that
does
all
the
stuff.
So
on
self-managed
you
still
log
in
over
openssh
first
and
then
it
hits
gitlab
show.
C
You
know
a
critical
part
of
the
infrastructure
because
yeah
it
satisfied
a
need
to
you
know,
be
in
front
of
rails
and
puma
and
take
a
lot
of
the
load.
I
think
that's
why
they
called
it
workhorse,
but
yeah
interesting
that
it
just
started
from.
I
guess
one
person's
idea
and
just
you
know,
hacking
away
on
the
weekend
and
now
it's
where
it
is
now.
A
One
of
our
other
key
features,
which
is
gillette
ci,
actually
started
out
much
the
same
way,
I
think
back.
Then
there
was
a
lot
of
debate
as
to
you
know,
should
we
have
ci
as
a
separating
or
should
we
you
know
bake
it
right
into
gitlab
camille?
I
think.
What's
the
one
that
said,
you
know
what
I'm
just
gonna
do
this
and
it
happened
the
way
it
did
and
it
has
become
quite
core
to
our
product.
B
A
Yeah,
I
think
in
many
cases
scaling
is
actually
pretty
okay.
You
know
what
maybe
it's
not,
but
I
think
it's
quite
intuitive,
like
you
know,
if
you
want
to
have
multiple
application
servers,
because
you
know
you
have
too
many
incoming
web
requests,
you
need
two
of
these
right
and
then
once
you
have
two
of
these,
you
run
into
the
problem
of
that
you
know
having
multiple
applications
hit
your
postgres,
and
then
you
know
how
do
they
actually
talk
to
you,
redis
and
stuff,
like
that,
so
it
kind
of
grows
from
there,
but.
A
A
A
A
B
A
All
right,
then,
I
mean
we
are
at
time
anyway.
So
thanks
everyone
for
coming.
I
I
hope
this
actually
helped
you
get
a
better
understanding
of.
You
know
how
gitlab,
how
the
different
github
components
work
together
and
again.
My
hope
is
that
you
will
take
this
understanding
and
build
out
your
understanding
and
also
build
out
our
training
materials
and
our
documentation,
so
that
you
know
this.
This
doesn't
become
like
the
one
resource
that
you
use
for
years.
On
that
I
I
sincerely
hope
that
doesn't
happen.