►
Description
Service Mesh Performance Community Meeting - Sept 16th, 2021
Agenda:
- [Zain] Review of Nighthawk’s Prometheus integration
- [Navendu] Share Nighthawk binaries and gRPC stub
- Creating an outline for Nighthawk documentation and how Meshery integrates with it Document Nighthawk architecture and internals.
- [Rudraksh] Moving Nighthawk out of Meshery’s container
- [Anirban] Adaptive Load Controller in Nighthawk
- Slides being published on GetNighthawk.
- [Lee] Service Mesh Performance @ KubeCon
- [Lee] Goal: Service Mesh Performance Benchmarks
- [Lee] Clarifying Service Mesh Working Group, GetNighthawk, Service Mesh Performance
Join the community at https://layer5.io/community
Find Layer5 on:
GitHub: https://github.com/layer5io
Twitter: https://twitter.com/layer5
LinkedIn: https://www.linkedin.com/company/layer5
Docker Hub: https://hub.docker.com/u/layer5/
A
B
C
C
I
have
worked
on
many
companies
since
last
four
and
five
years
and
basically
I
worked
on
cloud
and
it
is
also
like
humanity
and
sre
tools,
and
there
are
lots
of
tools
I
have
worked
upon
and
mainly
on.
I
have
worked
on
ansible
and
clouds
and
some
security
tools,
and
this
is
like
a
custom
like
I
have.
A
B
D
E
D
E
E
Okay,
you
said
you're
on
the
the
a.s
side,
the
advanced
services
side,
cool,
very
good,
very
good,
joel.
That
reminds
me
an
engineer
from
cisco
was
just
had
just
opened
a
pr
this
morning
on
a
different
measuring
on
a
related
project.
So
nice,
it's
good
to
see
more
more
network-centric
folks
joining
that's
good
yeah
nice
to
have
you
joel
it's
a
good
day
to
join.
Thank
you
yeah!
E
It's
a
good
day
to
join,
actually
we're
going
to
talk
a
little
bit
about
some
of
the
charter
of
the
project
and
actually
just
considering
that
most
of
us
are
relatively
new
to
well.
I
think
you're
you're
in
good
company,
if
you're,
somewhat
new
to
service
meshes
in
general,
there's
a
lot
of
resources
to
actually
point
you
to
in
terms
of
exploring
ramping
up
or
exploring,
and
so
nice
good
good
sorry
to
interrupt
navindu.
I
just
wanted
to
make
sure
I
got
introduced
to.
A
Joel
surely
yeah
thank
you
joel
for
the
introduction
and
welcome
to
the
community.
So,
let's
get
started
with
the
meeting.
Welcome
everyone
to
the
smp
community
meeting
today
is
the
16th
of
september,
and
we
have
nine
people
on
the
call.
Today
we
have
to
have
to
move
a
couple
of
items
to
next
week,
as
some
of
the
folks
were
not
able
to
join
today's
call
so
we'll
get
to.
A
We
will
discuss
more
about
those
in
the
next
call
and
to
give
some
idea
about
the
I
mean
like
the
first
topic
for
today.
Is
it's
a
review
of
prometheus
integration
with
night
talk,
so
I
understand
that,
like
building
night
talks
takes
a
takes
up,
a
lot
of
resources
and
zane
was
having
some
issues
with
with
building
network.
So
what
I
can
do
is
I
can
share
the
binaries
and
probably
the
grpc
client
stuff,
so
that,
like
everyone,
can
get
on
board
and
start
testing.
A
E
E
E
And
nighthawk
is
written
in
c,
plus
plus,
like
envoy,
is
nighthawk
and
fortio
work
differently.
As
a
matter
of
fact,
there
are
many
load
generators
out
there,
there's
one
that
we
haven't
spoken
about
a
lot.
As
a
matter
of
fact,
I
wonder
if
we
shouldn't
invite
this
particular
load
generator
to
come.
Engage
in
the
project
engage
here
meaningfully
the
the
project,
the
load
generator,
is
hyper
foil
and
they've
done
some
good.
Some
good
stuff
they're,
aware
of
smp
of
this
project
service,
mesh
performance
and
one
of
the
other
maintainers
from
red
hat.
E
Auto
was
telling
them
about
surface
match
performance,
and
so
maybe
we
can
bring
them
in
and
see
if
we
can't
collaborate.
Okay,
good,
so
there's
a
backdrop
as
to
why
we're
talking
about
load
generators.
Why
we're
talking
about
nighthawks
specifically,
is
because
nighthawk
has
some
intriguing
characteristics
to
it.
This
load
generator
can
be
extended
to
incorporate
well
well,
you
know
what
I
won't
describe
it,
because
anirban
just
gave
a
presentation
on
it.
Maybe
he'll
describe
it
a
little
bit
later,
but
but
point
is
the
nighthawk
is
important
to
us.
E
Nighthawk
is
the
reason
that
I'm
having
to
explain
it
is
because
a
lot
of
people
don't
know
about
it.
Why
don't
a
lot
of
people
know
about
it?
Well,
because
there
isn't
the
website
that
describes
the
project
and
how
to
get
it
and
what
it
does
it's
like.
Well,
that's
what
this
project
that's!
What
this
website
is
for,
if
you've
read
it
for
just
a
moment,
you
can
kind
of
tell
that
it's
two-thirds
of
the
way
done,
and
so
there's
been
a
number
of
contributors
that
have
helped
create
this.
E
This
small
site,
this
small
site,
has
a
set
of
empty
documentation.
So
night
hawk
itself
is
in
need
of
being
documented.
Part
of
the
documentation
should
reflect
on
a
sibling,
cncf
project.
Meschery
measuring
is
the
service
mesh
management,
plane,
meshery
incorporates
or
embeds
both
nighthawk
and
fortio,
so
mestre
makes
it
easy
to
run
performance
tests
using
either
of
these
load
generators,
and
so
these
projects
all
come
together
are
all
interrelated,
very
much
so
intentionally
and
so
navindu.
E
The
project
is,
it's
been
around
for
about
a
year
a
little
over
a
year,
but
has
been
slow
to
pick
up
because
it's
at
its
core
service
mesh
performance
is
a
spec,
and
I've
worked
on
a
bunch
of
specs.
For
my,
my
speaking
for
myself,
I'm
having
created
redfish,
having
done
docker
benchmark
the
1.0
from
having
done
a
couple
of
specs
like
the
specs
are
boring,
I
think,
and
but
this
surface
mesh
performance.
Yes,
it's
a
spec.
E
It
intended
to
be
a
universal
standard
of
enter
vendor
neutral
standard,
but
without
an
implementation
or
without
other
things
going
on
around
it.
It's
somewhat
boring
measury
is
the
initial
implementation
of
service
mesh
performance.
I
wouldn't
be
surprised
if
console
that
that
service
mesh
from
hashicorp-
I
wouldn't
be
surprised
if
at
some
point
they
don't
achieve
this
spec
they've
been
one
of
the
maintainers
of
s.
Ps
of
hashicorp
they've
been
very,
very
much
friends
to
the
project
and
helping
it
out.
E
E
Another
topic
would
be
get
nighthawk.
These
are
the
different
initiatives
inside
that
working
group.
We're
already
talking
about
these
different
initiatives
anyway.
It's
just
that
the
title
of
the
meeting
is
service
mesh
performance,
and
that's
not
the
only
thing
that
we're
doing
here
so
I'll
send
out
an
email
on
the
mailing
list,
just
to
kind
of
get
everybody's
vote
or
perspective
or,
and
if
anybody
has
a
perspective
now,
please
you
know
suggest
one
way
or
the
other.
E
E
I
don't
know
20
of
them
that
are
well
written.
There
need
to
be
more
defined
and
written
so
that
this
can
be
a
forum
or
it
is
a.
The
service
mesh
working
group
has
been
a
forum
for
advancing
that
thought.
So
that's
another
component
to
our
future
discussions.
If
we
change
this
meeting
to
be
the
service
mesh
working
group
meeting,
part
of
what
we
would
also
discuss
here
is
a
little
bit
about
smi
service
mesh
interface,
and
it
relates
to
s
p
quite
a
bit.
These
are
two
standards.
E
Two
standards
for
service
mesh
for
two
abstractions
for
service
meshes
there's
a
third
one-
that
we
won't
talk
about
right
now,
but
but
suffice
to
say
that
that
this
community
has
done
a
lot
around
smi
as
well,
and
around
mesheriy
and
they've
brought
meshary
and
smi
together,
because
mesherie
is
the
official
conformance
tool
for
smi.
So
if
so,
if
you're
unfamiliar
briefly
smi
has
been
around
for
a
couple
years
now
was
announced
that
kubecon
eu
in
barcelona
was
an
initial.
E
Our
meshery
was
an
initial
launch
partner
with
smi.
They
both
have
a
similar
vision
around
or
similar
understanding.
The
world
isn't
comprised
of
a
single
service.
Mesh
like
istio
is
the
most
popular,
and
yet
there
are
20,
plus
other
service
meshes
out
there
and
so
service.
Mesh
interface
is
a
specification
that
that
defines
common
functionality
that
you'd
find
across
you
know
any
service
mesh,
and
so
it
provides
a
common
api.
Common
interface
really
focused
on
service
mesh
functionality.
E
So
you
can
use
one.
You
can
interface
with
one
api
to
get
at
that
functionality,
irrespective
of
what
surface
mesh
you're
using
so
smi
is
to
service
meshes
as
terraform
is
to
multi-cloud,
if
you
will,
except
for
smi
as
a
spec
and
doesn't
have
any
actual
tooling,
just
like
s
p
is
a
spec
and
isn't
actual
tooling.
E
Hence,
something
like
meshri
comes
in
as
an
implementation
of
smi
and
has
an
implementation
of
smp
and
is
the
tooling.
Well,
is
one
of
the
tools
that
implements
those
specs,
I'm
just
kind
of
kind
of
covering
the
topics.
There's
another
topic
that
follows
another
initiative:
there's
two
other
initiatives
that
fall
into
the
service
mesh
working
group,
so
the
other
one
is
well
it's
a
something.
That's
yet
to
be
defined.
It's
a
concept.
It's
been
written
about,
written
down
and
spoken
about,
and
it's
colloquially
like
called
mesh
mark.
E
This
is
the
the
notion
here
is
that
we
would
create
a
simple
index,
a
new,
a
very
a,
very
concise
way
of
articulating
how
well
you're
running
your
mesh,
and
it's
it's
it's
more
than
how
well
it's,
how
well,
under
your
constraints
or
under
how
or
how
well
you
how
well
you're
running
the
surface
mesh
and
and
also
the
workloads
of
the
mesh,
the
infrastructure
beneath
it.
In
accordance
with
your
specific,
what
you
value
boy,
it's
a
little
bit
abstract
kind
of
hard
to
so
I'll.
E
E
Let's
see,
there's
a
statement
in
here
that
captures
it
pretty
well,
its
purpose
is
to
convert
measurements
into
insights,
about
user
satisfaction,
so
an
application
performance
index
meshmark
is
intended
to
be
well
a
cloud
native
performance
index
or
a
service
mesh
performance
index,
and
it's
intended
to
provide
a
very
a
very
concise
way
of
articulating
yeah.
The
the
you
know
how
well
you're
running
your
infrastructure,
so
aptx
or
like
meshmark,
like
aptx,
would
boil
down
to
a
single
number.
E
E
E
E
What
charts
and
metrics
you
use
to
measure
all
that
and
then
to
be
able
to
convey
that
someone
else
is
like
well.
My
setup
is
totally
different
than
what
you,
even
if
it
was
very
much
the
same.
It's
like
yeah.
So
anyway,
what
we're
trying
to
do
is
like
we're
trying
to
do
a
bunch
of
things,
but
but
with
meshmark.
One
of
the
things
that
would
be
accomplished
is
conversations
would
become
concise.
E
You
also,
then,
part
of
what
is
being
facilitated
here,
part
of
the
initial
vision
for
surface
mesh
performance
and
for
measuring
it
was
to
be
able
to
answer
the
question
that
people
ask
a
lot
like
service.
Mesh
is
great.
What's
the
overhead
of
these
things?
How
much
is
it
going
to
cost
me,
or
what
can
you
characterize
that,
like
I'm
getting
a
lot
of
value?
What's
how
many
cpus?
E
So,
as
people
run
performance
tests
using
meshri,
it
can
not.
It
can
gather
up
those
test.
Results
eventually,
part
of
what
service
mesh
performance
should
do
will
do
is
analyze
those
4
200
tests
and
then
say
things
like
you
know,
extract.
You
know,
hopefully
help
inform
the
world
about
here's,
how
expensive
the
most
expensive
mesh
is,
or
the
most
expensive
container.
E
Here's
the
cheapest
and
lightest
waiter,
here's
the
like,
whatever
insights,
can
be
extracted
and
it's
not
to
pit
service
meshes
against
one
another,
but
it's
to
help
inform
users
to
help
make
decisions
and
choices
about
what
mesh
to
use,
how
to
configure
it.
How
do
you
know
if
you've
tuned
it?
Well?
What
what?
How
should
you
tune
it
that
kind
of
a
thing
so
guys?
I
guess
I
I
apologize.
E
I
didn't
know
I
was
gonna
like
rant
at
you
for
a
while,
but
I
figure
that
many
of
you
may
not
be
aware
of
all
those
initiatives
and
kind
of
concepts
that
are
at
play
here,
and
I
wanted
to
give
credence
to
my
suggestion
that
we
changed
this
to
the
surface
mesh
working
group
because
there's
a
lot
of
things
to
do
and
that
are
going
on.
And
if
we
don't
have
these
discussions
here,
then
we're
gonna
have
to
you
know,
then
we'll.
E
Something
I
didn't
say
was
part
of
the
goals
here,
and
these
are
common
goals,
is
to
like
inform
the
world
of
patterns.
Great
inform
the
world
of
performance
tests
like
like
what
should
you
be
testing?
And
why
and
when,
like
yeah?
Is
there
a
common
benchmark
that
you
could
use
to
assess
your
environment.
E
E
E
E
One
of
one
of
the
things
that
we
want
to
achieve
is
like
running
a
bunch
of
performance
tests
and
ultima
and
finally
publishing
them.
Like
finally
saying
here's,
some
actual
data
like
here's,
what
you
should
you
know
you
know,
checking
and
seeing
like
istio
has
been
trending
as
just
as
an
example,
it's
been
trending,
either
more
performant
in
its
later
releases
or
it
hasn't
or
it
has
regressed.
And
how
do
you
know
that
these
service
meshes
aren't
publishing
some
of
them
publish
performance
tests?
Istio
no
longer
has
a
working
group
on
performance.
E
Or
scalability
they
consider
that
they've
mostly
achieved
what
they
were
looking
to
do
and
haven't.
You
know,
aren't
doing
that.
But
how
do
you
compare
across
them?
And
so
that's
part
of
the
initiative
here
and
so
there'll
be
any
number
of
any
number
of
you
that
are
on
the
call
that
can
really
help
out
with
this.
That
could
put
your
name
on
a
cncf
blog
post
that
could
be
talking
at
kubecon.
That
could
be
that
can
be
helping
run
these
tests
we
they're
there.
E
We
finally
have
tooling
nighthawk
and
meshery
and
to
to
go
run
such
tests
mescheri
will
automate
the
deployment
of
10
different
types
of
service
meshes,
it
automates
the
deployment
of
sample
of
applications
and
the
performance
testing
of
them,
the
analysis
of
them
and
the
collection
of
that
analysis.
So
no
longer
is
it
a
big
effort
to
go
like
create
a
bunch
of
scripts,
and
you
go.
E
Pull
in
to
ansible
is
on
the
tip
of
my
tongue
because
a
tool
it
said
it,
but
no
longer
is
it
necessary
to
go
cobble
together
all
that,
rather
it's
in
a
single
tool
to
go
perform
that
so
so
actually
we're
in
need
of
people
to
help
define
what
this
would
look
like.
We
can
get
access
to
the
cncf
labs
anytime
that
we
want
go
grab,
20,
bare
metal
servers
through
packet
and
lay
down
kubernetes.
You
know,
lay
down
a
cluster
and
start.
E
So
I'm
sorry,
I
yeah
you
said
navendu
back
to
you
at
the
specific
items
on
get
nighthawk
would
be
yeah
nighthawk
itself,
as
a
load
generator
doesn't
have
any
documentation,
has
one
readme
and
that's
it
and
it's
fairly
complex
a
nearby.
Do
you,
I
mean
just
as
you'd,
given
a
presentation
this
last
friday
on
it.
A
Not
really,
I
have
not
worked
much
on
the
dockside
right
now.
I
have
not
checked
it
out.
I
just
need
to
check
it.
You
can
just
let
me
know
like
what
is
the
standard
format
kind
of
you
are
following
for
the
other
projects.
So
probably
I
can
just
have
a
look
at,
but
I
did
not
have
a
look
at
the
site
right
now.
I
was
just
making
the
presentation
yeah
yep,
yep,.
E
E
A
E
E
B
F
E
G
G
G
It
would
be
good
if
we
dig
up
more
on
them
and
probably
document
them
on
the
site
like
it
would
be
good
that
people
come
to
know
about
them.
Mainly,
there
are
two
clients,
nighthawk
client
and
nightbox
server
service.
This
is
a
grpc
client,
and
this
is
your
cli
and
you
can't
trigger
them,
and
you
can
generate
load
on
your
services
when
you
run
test
using
nighthawk
lined
it
internally
gives
you
the
ability
to
convert
your
results
in
a
compatible
format,
like
whatever
form
that
you
like.
There
is
a
flag
for
that.
G
However,
the
grpc
service
only
returns
the
results
in
a
single
format
that
is
nighthawk
native
format.
So,
for
that,
nighthawk
provides
this
binary.
Let
me
zoom
in
a
bit
the
output
transform
binary
and
you
can
use
that
to
convert
it
to
any
format
you
like
all
of
these
binaries.
All
of
these
clients
are
made
using
grpc.
So
these
are
grpc
client
and
they
can
be
generated
using
their
protocols
that
nighthawk
provides.
So
basically,
this
is
what
we
are
going
to
use
for.
G
So
right
now,
my
main
focus
with
this
vr
is
on
getting
nighthawk
out
of
mystery
servers
image.
If
you
would
run
tests
right
now,
they
would
be
just
it
would.
The
service
would
be
running
inside
mystery
server
and
then
it
would
be
creating
internal
processes
and
everything
would
be
happening
inside
misery
server.
This
is
limiting
this
limits,
our
performance.
G
G
B
G
A
little
further
because
some
timeouts
and
some
stuff
has
to
be
more
tested
and
figured
out
once
this
gets
in
mystery
server
would
be,
would
not
be
running
the
nighthawk
service
internally
other
than
that
I'd
like
to
show.
How
are
we
achieving
this
so
basically
get
nighthawk
acts
as
a
client
provider.
G
Here
a
go
native
line
trapper
here
and
using
that
I've
created
this
client
and
oh
so
this
is
basically
this
deploys
nighthawk
here
it
uses
a
kubernetes
manifest
for
that,
and
then
this
is
the
one
that
uses
the
service
that
was
deployed
in
the
above
function
to
generate
load
it.
It
has
some
test
parameters.
G
This
is
adapted
from
get
nighthawk
like
the
client
that
it
provides
and
yeah.
Basically,
that's
it
it.
It
would
have
been
nice
if
a
demo
was
done
using
mystery
itself,
but
I've
created
a
toy
client
for
now
which
can
be
used
for
doing
this.
So
this
is
my
toy
client,
and
this
expects
an
address
to
a
server.
G
E
G
This
is
the
service
listening
on
48443
and
I'll
run
my
client
using
this
command.
I've
saved
it
in
its
client.
I
just
showed
it
here.
It's
a
very
small
client
made
using
grpc
protocols
from
get
nighthawk
and
when
I
simply
run
this,
it
takes
the
target
of
a
service
and
the
nighthawks
have
this
address,
and
here
we
go
it's
generating
now.
G
G
G
I'm
running
it
here.
So
this
is
my
nighthawk
light.
It
comes
in
the
nighthawk
day
or
get
nighthawk
image.
If
you
just
pull
it
and
execute
it,
it
would
run
nighthawk
for
you
and
generate
load.
So
I
hope
that
helps
if
it
doesn't
then
feel
free
to
reach
me
out
so
that
we
can
talk
on
that
yep.
That's
it.
E
Nice,
I
can't
let
me
add
to
that
briefly,
to
just
help-
help
bring
it
home
a
little
bit
with
what
that
looks
like
in
measuring
to
to
run
a
performance
test
so
at
least
using
this,
the
mesh
map
plug-in.
So,
if
you're
looking
at
a
service
mesh
deployment-
and
you
have
your
apps
deployed
on
it.
So
in
this
case
I
think
the
bookinfo
app
is
deployed
here.
E
E
A
A
Maybe
we
can
move
on
to
the
next
topic,
which
is
kind
of
open-ended
on
kubecon,
so
service
mesh
performance
being
a
cncf
sandbox
project.
Has
I
mean
we
have
a
we?
We
really
get
a
lot
of
visibility
in
at
kubecon,
so
we
need
to
leverage
it
and
try
to
make
the
project
more
successful.
So
lee
do
you
have
some
thoughts
on
that.
E
Yeah,
so
at
kubecon
there'll
be
a
one
or
two
spots
where
well,
where
all
of
you
are
invited,
and
hopefully
at
some
point
one
or
more
or
all
of
you
are
sharing
things
that
you're
doing
in
the
project
here
with
the
with
others
that
are
interested
it's
one
of
those
things.
That
is
something
that
that
people,
when
they
see
service
mesh
performance
as
a
project,
and
they
no
doubt
when
they
come
to
learn
about
it.
E
There's
other
folks
that
are
involved
here,
but
but
it'll
take
someone
stepping
up
and
saying
yeah,
hey
I'd
like
to
assist
in
or
lead
the
way
in
running
those
tests
and
and
then
doing
a
little
bit
of
assessment,
helping
publish
those
like
that's
the
kind
of
thing
that
we
would
want
to
share
at
kubecon
and
tell
people
about
the
resources
that
are
available
to
them.
Tell
them
about
how
to
use
these
tools
in
their
own
environment
so
that
they
can
do
their
own
assessment
of
how
well
their
infrastructure
is
running.
E
There
was
some
technicals
what
he
was
showing,
and
I
don't
know
if
it
was
evident.
Like
the
the
reasons
why
he's
doing
this
so
he's,
he
I
think
he
had
said
like
nighthawk
is
embedded
in
mesherie
today
and
that's
great
super
convenient
go,
deploy,
meshery
you've
got
your
choice
of
three
different
load.
Generators
go
run
the
tests
great
choose
the
different
ones;
they
do
different
style
of
analysis.
E
E
What
it
doesn't
allow
us
to
do,
though,
is-
and
this
is
what
rudraksha
is
doing-
he's
taking
and
detaching
nighthawk
from
meshary
such
that
the
user
experience
still
feels
like
it's
one
tool,
but
rather
than
that
experience
where
I
was
showing
you
all
kind
of
this
form
that
you
would
fill
in
to
go
run
a
performance
test
that
part
of
there
would
be
a
check
box
on
that
form.
That
says:
did
you
did
you
want
either
a
checkbox
or
what
some
input
field
that
says,
how
many
instances
of
the
load
generator?
E
E
And
today
today
you
can't
or
it
or
today
you
you
can't,
because
it's
just
a
single
instance
load
generator.
You
can
generate
a
ton
of
load
like
don't
get
me
wrong,
but
things
become
you
get
a
higher
fidelity
set
of
data
or,
like
you,
get
data
from
various
vectors.
If
you've
got
multiple
load
generators
hitting
either
the
same
endpoint
like
the
same
url
under
test
or
maybe
you've
got
multiple
endpoints.
E
E
E
So
if
any
of
that
intrigues,
you
please
do
I'll
support
you
in
in
getting
there
with
the
two
million
things
and
not
just
me,
but
the
other
maintainers
and
and
people
like
rudraksha
and
things
so
that's
it
yeah.
I
mean
next
time
we
meet
in
a
couple
of
weeks
here,
one
hopefully
we're
meeting
under
the
umbrella
of
the
service
mesh
working
group
and
I'll
make
sure
that
that
that
gets
onto
the
cncf
calendar.
E
A
So
my
next
step
would
be
on
the
multi
threading
part
as
to
make
it
how
to
make
it
more
scalable
from
the
application
programming
perspective.
So
I
just
added
few
things
which
I
found
interesting
and
just
added
a
few
things
here
so
like
what
are
these
some
of
those
benchmarks
parameters?
What
is
so?
You
can
just
go
up.
You
can
just
scroll
up
navindu.
A
These
are
from
the
driver's
side,
so
yeah
come
down
yes,
so
I
have
added
this
a
couple
of
things
which
can
also
increase
the
like
rps,
based
on
where
the
request
is
in
like
bound
for
so
is
it
like
io
bound
or
cpu
about
so
based
on
that
some
kind
of
matrices
or
some
kind
of
benchmark
results
I
have
shown
and
based
on
that,
we
can
also
test
it,
and
can
you
come
down
a
little
bit
below
so
this
is
for
cpu
board.
Okay,
can
you
come
down?
A
Okay,
so
slide
number
is
seven.
Okay,
slide
number
is
seven
okay,
so
these
are
the
three
things
which
we
need
to
consider.
Okay,
latency
is
fine,
but
what
I
was
telling
is,
we
are
actually
using
all
three,
not
just
latency,
because
latency
depends
on
round
trip
type
and
to
measure
it.
We
can
actually
send
some
packets
from
us
and
we
can
see
that
how
much
latency
is
added.
So
this
will
make
a
differe.
A
It
will
give
a
different
network
performance
altogether
based
on
the
benchmarks
which
we
have
created.
So
we
can
just
induce
those
these
things,
because
distance
makes
a
lot
of
effects
in
a
big
way
that
that
is
one
thing
and
second
is
rps.
So
anyway,
whatever
rps
I
talked
about
was
for
the
driver
part,
but
this
is
like
request
per
second.
So
again,
anyway,
we
are
going
to
measure
it
and
make
it
more
adaptable.
A
This
is
fine,
but
again
another
thing
is
scalability,
so
by
adding
more
either
doing
vertical
or
horizontal
scaling,
but
we
are
going
for
horizontal
scaling
where
we
are
adding
more
servers
or
machines.
So,
based
on
that,
how
many
requests
we
can
we
can
reach
so
that
and
what
is
the
kind
of
the
limit,
after
which
the
application
can
no
longer
handle
any
more
requests,
so
that
test
also,
we
need
to
do
to
actually
find
out
like
what
are
our
benchmark
parameters,
and
is
it
really
serving
the
purpose.
A
I
would
have
to
look
into
this
back
to
get
a
deeper
understanding,
but
yes,
like
I
agree
that,
like
we
have
different,
metrics
and
latency
should
not
be
the
only
thing
that
we
know.
Latency
also
has
one
thing.
So
if
you
are
testing
it
from
india
and
if
you're
testing
you
are
sending
the
packets
from
us
to
india,
there
is
a
different.
A
E
E
E
Not
all
service
meshes
have
gateways
by
the
way,
so
an
ingress
gateway
and
an
egress
gateway
yeah.
Those
are
concepts
specific
to
some
meshes,
but
not
universal
to
all.
So,
okay,
some
service
meshes
sidecar.
Their
proxies
most
do
some
do
not
some
run
their
proxies
as
node
agents
as
daemon
sets.
Okay,
well,
this
model
like
so
the
model
needs
to
evolve.
This
one
was
sourced.
E
A
E
E
One
thing
I
had
had
was,
if
you're
not
on
the
community
at
if
you're,
not
on
the
s
p
mailing
list,
I
would
encourage
you
to
be,
but
we'll
we're
going
to
try
to
be
a
bit
more
asynchron.
I
try
to
advance
things
in
between
the
times
that
we
meet
and
so
we'll
for
this
project,
we'll
probably
end
up
using
mailing
lists
for
that,
and
you
can
find
that
mailing
list
on
the
site
itself
on
the
s
p,
spec
site.
E
B
E
B
E
A
Okay
lee,
I
just
have
a
thought,
so
I
have
just
talked
about
some
of
those
performance
tuning
from
the
driver
or
that
side.
So
is
that
required
because
anyway,
it's
used
and
it
can
used
to
be
used
to
increase
the
throughput,
but
I'm
not
sure
whether
machete
is
actually
using
those
kind
of
concepts.
So
just
just
thinking
like
should
we
include
this
or
we
just
go
from
that
bench
box,
kpi
bench
box
only
not
from
the
driver
side.