►
From YouTube: OpenShift Commons Briefing #28: Continuous Performance Testing for OpenShift Applications
Description
Michael Sage, from BlazeMeter, will lead the conversation around Continuous performance testing and will show you one way to meet the high expectations from modern users.
For the latest information on OpenShift 3.1 and available briefings, please visit http://commons.openshift.org or subscribe to the OpenShift Blog (https://blog.openshift.com).
The OpenShift Commons exists to provide a platform for customers, partners, developers and other open source technology initiatives to collaborate, share and accelerate the pace of innovation and adoption of OpenShift globally. The OpenShift Commons represents a new open collaborative community model designed to facilitate communication and sharing of best practices, feedback and development across the many open source initiatives that integrate with OpenShift. The best way to get involved is to join the conversation today at http://commons.openshift.org
A
A
Well,
welcome
everybody
to
this
week
the
28th
open
ship,
Commons
briefing
and
we're
really
pleased
to
have
Michael
sage,
the
chief
evangelist
from
Blaise
meter
with
us
today
to
talk
about
continuous
performance
testing
and
we'll
be
doing
a
couple
more
of
these
external
briefings
by
different
service
providers
over
the
next
coming
months.
So
we're
hoping
to
get
a
lot
more
if
you
have
one
that
you're
interested
in
hearing
from.
A
Let
me
know
if
you
have
questions
and
answers
here
if
you
could
hold
them
to
the
end
of
the
presentation
that
would
be
great
and
enter
them
into
the
chat
room
and
well,
if
it's
it's
burning
off,
I'll,
try
and
answer
it
in
the
chat
or
Michael
will
pop
over
there.
But
we've
got
a
lot
to
cover
today,
so
I'm
hoping
we
can
just
kick
it
off
and
that
Michael
now
introduce
himself
and
kick
it
off
great.
B
Thank
you
so
much
Diana
and
I'm
happy
to
be
here,
hello,
OpenShift
world.
My
name
is
Michael
sage,
as
you've
heard
and
I
am
chief
evangelist
for
blaze
meter.
My
background
goes
way
back
to
the
old
mercury
days.
I've
been
doing
performance
testing
for
a
long
time
and
I've
kind
of
followed.
The
trends
from
the
old
days
of
client-server
performance
testing
with
thick
heavy
windows
based
tools
into
the
modern
era,
where
we're
all
we're
all
about
continuous
integration
and
continuous
deployment
and
all
sorts
of
innovative
new
ways
to
deliver
and
test
applications.
B
So
obviously,
the
point
of
this
slide
is
to
induce
the
frustration
that
you
have
when
you're
waiting
for
websites
to
load
and
these
days
we
know
that
users
expectations
are
higher
than
they've
ever
been,
in
fact,
we're
hearing
stats
that
are
really
remarkable.
Things
like
49%
of
people
expect
pages
to
load
in
under
two
seconds,
and
thirty
percent
expect
a
one-second
response
time
and
it's
really
converging
on
instant
people
really
want
their
devices
or
their
websites
and
so
forth
to
behave
as
to
behave
as
actual
objects.
B
Do
we
expect
our
ABS
or
are
our
pages
to
load
right
away
just
like
if
we
turn
on
the
television
when
that
means
we
have
to
test
and
performance
testing
until
now
has
been
generally
relegated
to
a
later
stage
in
the
waterfall
type
process
and
I'm
sure
many
people
on
the
call
recognized
this
kind
of
graph.
That's
basically
a
waterfall
approach
where
we
had
each
stage
was
done
before
the
next
stage
was
taken
off
this
slow
and
kind
of
methodical
delivery
chain
didn't
really
work.
B
Defects
got
through
pretty
easily,
they
were
very
hard
to
troubleshoot,
especially
because
they
were
discovered
too
far
down
the
pipeline
to
remember
what
that
code
was
all
about,
and
when
we
did,
this
kind
of
waterfall
approach.
Load
testing
was
in
fact
the
last
of
the
last
thing.
It
was
relegated
to
this
very
final
stage
of
the
almost
final
step
and
it
was
generally
done
as
a
war
room
exercise,
and
some
of
you
might
remember
this.
B
We
get
everybody
into
this
big
room
and
it
takes
a
few
weeks
or
months
to
develop
the
scripts
that
represent
the
load
traffic
and-
and
you
know
we
get
the
monitoring.
People
get
the
business
owners,
we
get
the
developers,
everybody
comes
together
for
this
big
event.
Sometimes
this
is
done
in
advance
of
some
occasion
like
Black
Friday
or
they
up.
For
example,
now
we
have
the
Super
Bowl
coming
or
March
Madness
and
teams
will
get
ready
for
this
big
load
testing
event
to
see
if
their
application
can
sustain
the
traffic
they
expect.
B
This
is
still
important
and
I
definitely
want
to
emphasize
that
as
we
go.
This
is
an
important
way
of
approach
to
load
testing.
It
still
has
its
place,
but
it
really
doesn't
help
us
in
the
modern
era,
because
basically,
continuous
integration
has
proven
itself,
and
we
know
now
that
continuous
delivery
pipelines
work.
We
discovered
defects
earlier,
we
can
fix
them
more
cheaply
and
more
easily,
and
we
can.
B
We
can
release
features
to
our
customers
that
are
satisfying
our
requirements,
whether
that's
performance
or
functionality
or
innovation,
and
we
want
to.
We
want
to
be
able
to
benefit
the
business
that
way
so
with
continuous
delivery
approaches.
We
need
a
new
way
of
conducting
our
performance
tests.
We
want
to
test
source
code,
we
want
to
test
the
new
code
that
we
commit,
preferably
right
in
our
desktop
without
having
without
having
to
wait
to
submit
a
ticket
for
some
specialist
team
to
create
scripts
for
us
to
test
that
code.
B
We
want
to
be
able
to
do
it
in
a
familiar
environment.
We
also
want
to
test
our
CI
builds.
We
want
to
be
able
to
see
that
every
build
that
we
push
through
works
and
performs
as
expected,
especially
when
it
involves
multiple
code
commits
and,
of
course
we
want
to
test
our
deployments.
We
want
to
test
staging
rehearsal
environments,
QA
environments
and
even
production
environment.
So
we'll
talk
a
little
bit
about
some
of
the
specific
objectives
for
those
different
kinds
of
stages
that
we're
going
through
here.
B
I
want
to
introduce
Taurus,
and
this
is
the
game-changing
tool
that
allows
us
to
do
the
kind
of
performance
testing
we
need
at
each
important
stage
of
delivery.
You
remember
the
old
tools,
loadrunner
or
silk
performer
and
so
forth.
These
tools
don't
really
work
in
the
kind
of
process
that
I
just
introduced.
That
I
just
went
through
there
they're
heavy
tools
that
have
to
be
installed
on
the
way
those
desktop
they
generally
have
a
lot
of
complexity
to
them
and,
there's
you
know
big
rich
GUI,
and
it
takes
them
long
to
learn
them.
B
We
want
to
introduce
a
technology,
that's
familiar
and
makes
it
super
simple
for
developers
and
other
team
members
to
get
tests
up
and
running
fast,
and
so
what
we
did
is
we
created
a
llamo
based
approach
and
for
those
of
you
who
work
with
configuration
or
pretty
much
any
kind
of
delivery
or
deployment
mechanisms.
These
days
you'll
find
llamo
is
pretty
familiar
with
the
llamo
based
test
in
Taurus.
B
We
will
100
current
users
doing
the
things
we're
going
to
tell
them
to
do
getting
the
homepage
or
getting
a
shopping,
cart
whatever
it
might
be,
and
we
want
to
run
those
100
concurrent
users
for
5
minutes,
I'm,
going
to
ramp
up
1
minute
too,
and
that's
kind
of
a
gradual
build
up
of
that
load
from
0
to
100
over
60
seconds.
Sometimes
we
do
that.
Just
not
to
overwhelm
the
server.
The
next
thing
you
want
to
do
is
describe
the
actual
requests.
B
These
are
the
pages
or
the
code
paths
URIs
that
are
triggered
by
the
test
execution,
and
you
can
see
here
pretty
standard,
HTTP
stuff
right.
We
have
a
couple
of
URLs.
If
it's
a
get
request,
you
don't
even
need
to
say
anything
about
it.
You
see
that
index
dot,
PHP,
just
gonna,
know
that
tarz
will
know
that
that's
a
get
request.
The
second
one
is
a
post
request
and
where
we
wanted
to
add
a
header,
because
there's
going
to
be
a
JSON
payload
here
and
we
also
have
a
body
that
describes
two
values.
B
B
You
found
that
build,
so
these
are
just
some
some
general
descriptions
of
what
can
have
what
that
needs
to
go
in
this
yeah
mo
to
to
make
this
test
war.
It's
pretty
straightforward.
It's
not
a
very
complex
test.
Taurus
is
great
because
you
can
have
very
simple
tests.
You
can
have
very
complex
tests
and
you
can
actually
piece
them
out
and
sort
of
merge
them
together
at
runtime
and
I'll.
Show
you
how
to
do
that.
So
those
are
the
main
modules
that
I
just
wanted
to
introduce.
B
To
give
you
a
feel
for
how
Taurus
works
when
you're
running
these
tests
run
them
from
the
command
line.
The
command
line
is
bzt.
The
test
names
are
llamo.
That
could
also
be
JSON
and
you
can
run
two
or
three
or
four
together
and
Taurus
will
know
how
to
manage
those
different
sections
in
each
of
those
animals
and
run
them
as
an
intelligent
test.
B
When
you
do
execute
the
test,
you
get
a
nice
console-based
dashboard
that
shows
you
all
the
metrics
that
matter
choosey
the
response
times,
even
the
percentiles
of
response
times,
as
well
as
any
errors
that
are
happening
and
on
response
codes
and
things
that
you
want
to
keep
track
of.
When
you
run
this
test
from
your
desktop,
very
specifically,
you
can
you
can
see
the
number
of
hits
that
are
getting
to
each
end.
Point
the
number
of
failures
for
that
endpoint
and
the
average
response
time
tracked
so
already
as
a
developer.
B
Then,
of
course,
we
want
to
run
in
Jenkins,
or
our
builds
here
right
now
and
openshift
Jenkins
is
built
right
in,
and
so
you
probably
want
to
run
your
builds
in
Jenkins
and
have
these
tests
run
as
part
of
that
builder
as
a
post
build
job
and
there
we
can
do
it
just
as
a
shelter
right
and
here
what
you're
looking
at
is
just
an
example
of
a
few
tests
that
I'll
run
together
and
note
the
modules
console
disabled
equals.
True
in
the
upper
right.
B
That's
a
command
telling
tourists
not
to
launch
that
dashboard
that
ASCII
dashboard,
because
it
will
it
will.
It
will
fill
up
the
console
output
with
lots
of
text
that
you
don't
want
and
it
kind
of
makes
them
s.
So
that's
a
good
thing
to
remember
as
well
and
then,
finally,
of
course,
that
threshold
command,
we
want
to
set
those
response,
time
thresholds
or
those
failure
thresholds,
and
that
can
be
response
time
that
can
be
standard
deviation.
It
can
be
error
rates,
lots
of
different
possibilities
there,
for
whatever
actually
does
fail.
B
Your
build
or
in
your
in
your
criteria
should
fail
the
build
and
those
are
those
are
really
easy
to
set
up.
Of
course,
they
will
show
up
in
Jenkins
and
you
can
see
build
over
build
what
kinds
of
failures
or
what
kinds
of
problems
you're
having
with
response
time
as
you
commit
new
code,
as
you
run
those
tests.
Ultimately,
what
we
love
to
see
is
teams
getting
familiar
with
the
behavior
of
their
applications
and
then
kind
of
keeping
an
eye
out
for
what
I
call
millisecond
creep
the
build
over
build
over
build.
B
You
know
you
might,
you
might
say
to
yourself
well,
the
500
milliseconds
is
great
and
then
maybe
the
next
build
is
550
milliseconds,
and
you
think
you
know
what
that's
not
so
bad
either,
but
all
of
a
sudden,
a
week
later,
you've
done
20
releases
and
your
your
your
response.
Time
has
quadrupled.
So
those
are
the
kinds
of
things
you
want
to
start
to
keep
an
eye
on
that
you
couldn't
do
before
with
the
old
load
testing
tools.
So
with
that,
let's
go
into
a
demo
and
I'll
show
you
how
tourists
works
here.
B
B
Great
so
I
had
a
really
easy
time.
Setting
up
a
PHP
app
on
openshift
I,
actually
set
up
a
Python
app
as
well
and
I
was
playing
with
and
I
kind
of
got
into
a
little
bit.
I
did
end
up
deciding
to
use
my
own
Jenkins
server,
because
there
were
some
dependencies
in
thing
that
I
wanted
to
install
and
I
needed
to
have
root
access
and
so
forth.
B
So
so
what
I
did
is
I
just
basically
set
up
a
PHP
cartridge
and
it's
a
simple
app,
as
you
saw
in
my
tart
in
my
Attar's
example,
the
nature
of
this
demo
app
is:
it
will
allow
a
user
to
choose
some
cities
here,
let's
walk
through
it.
Let
me
choose
a
couple
of
cities
just
from
the
list
and
find
a
flight
go
ahead
and
choose
that
flight.
You
can
see
the
URLs
changing
here,
fill
in
the
credit
card
form.
B
If
you
need
to
made
this
a
super,
simple
lightweight
app
that
doesn't
require
much
of
anything,
but
that's
it
right.
Just
a
few.
A
few
end
points
a
few
pages,
a
few
interactions,
and
so
the
idea
with
Taurus
is
to
represent
that
in
a
llamo
file
represent
what
we
want
to
do
there
as
this
llamo.
So
now
you
can
see
my
text
file
here
and
it's
those
same
kinds
of
sections
Miyama
blocks
that
we
saw
in
in
the
demo.
B
Let
me
go
ahead,
I'm
going
to
actually
remove
that
for
now,
so
you
can
see
execution
and
scenarios.
I
have
200
concurrent
users,
just
I'm
I'm,
ready
for
10,
min
I'm,
sorry,
I'm
running
for
30
minutes
and
ramping
up
for
10
and
I
have
one
scenario
in
here:
it's
the
main
scenario,
and
it's
got
some
attributes
the
well.
You
can
have
multiple
scenarios
in
one
file.
Excuse
me,
then
you
can
just
toggle
them
using
the
descriptor
here.
So
that's
another
easy
way
to
kind
of
keep
things
organized.
B
One
thing
here
that
wasn't
in
the
slide
is
think
time
when
think
time,
for
those
of
you
haven't
done
much
load
testing
represents
those
gaps
that
are
natural
kind
of
pauses
for
users.
When
you
go
to,
for
example,
the
credit
card
page
and
the
app
I
just
showed
you,
you
may
want
to
account
for
the
time
it
takes
for
someone
to
type.
B
But
here
what
I've
done
is
I've
filled
it
out
a
little
further
I
have
my
first
URL
just
go
into
the
main
page
and
then,
at
this
time,
I'm
describing
again
and
I'm,
giving
it
a
label
I
want
in
my
reports.
I
want
this
to
show
up
as
homepage,
so
that
I
remember
what
it
is.
I
can
logically
relate
to
it
as
the
kind
of
part
of
the
app
or
the
page
in
the
app
where
the
load
is
is
being
sent.
B
The
second
one
is
the
flight
chooser,
where
I
call
two
cities-
and
here
are
my
arguments-
London
and
Rome.
Now
you
can
actually
draw
these
values
from
a
CSV
file
and
that's
easy
to
do
as
well.
So
when
you
get
into
tarah,
so
you
start
working
with
it,
you
can
parameterize
values
and
you
can
really
kind
of
get
sophisticated
in
exactly
the
same
way
that
you
will
have
done
and
it's
sort
of
the
older
style
tools.
B
So
that
said,
I'm
going
to
go
ahead
and
run
a
tourist
test.
Here,
let's
go
ahead
of
them,
that's
more
a
different
chill
all
right!
So
Horace
I
have
my
process
here.
You
can
see
I'm
going
to
go
ahead
and
run
one
called
complex
blaze,
which
is
the
one
that
we
just
saw
actually
I'll
run
the
all
diamo.
That's
that's
the
exact
one
we
were
just
working
with,
so
it's
very
simple
bzzt
all
right
now
and
Horace
won't
launch
and
it
looks
like
I
did
not
save
that
with
my
change.
B
Let's
go
ahead
and
do
that
and
go
back
to
try
it
one
more
time.
All
right.
So
parse
is
telling
me
there's
a
new
version.
It's
always
nice
to
be
reminded
to
upgrade.
We
just
introduced
some
really
cool,
selenium
support
for
those
of
you
have
done.
Functional
testing
or
work
with
selenium
tars
can
also
execute
those
kinds
of
tests.
Selenium
gatling
Grindr,
really
it's
what
our
aim
is
to
let
tourists
run
any
kind
of
open-source
tool.
That's
used
for
testing
right
now.
B
B
You
don't
really
have
to
think
about
it,
but
it
will
do
that
and
so
now
you
can
see
out
my
test
running
I
have
my
kind
of
8-bit
video
game
graphs
for
the
turning
over
here
on
the
left,
and
here
I
can
see
all
the
different
values,
the
percentiles
and
response
times
that
are
coming
back
from
the
application,
and
these
are
the
two
pages
that
I'm
working
with
on
the
on
the
OpenShift
hosted
application
there.
So
pretty
good
under
a
second
each
I'm,
pretty
happy
with
those
results.
B
It's
a
long
test,
I
put
some
long
times
and
there
so
I'm
going
to
go
ahead
and
just
stop
it
now.
That's
one
full
test,
but
really
what
we
want
to
think
about
is
is
rapid,
iterations
right,
so
you're
a
developer,
you're
working
just
on
your
code
and
maybe
that's
the
only
test
that
you
really
care
about
and
other
folks
are
managing
their
test
cases,
or
maybe
even
metafiles
like
execution
or
reporting
options,
and
so
what
you
can
do
with
Taurus
is
split.
B
Those
up
excuse
me,
for
example,
I've
put
a
separate
module
here
just
for
reporting.
In
fact,
blaze
meter
hosts
Taurus
reporting
for
free.
So
if
you
want
to
see
some
pretty
graphs
and
such
you're
welcome
to
use
our
service
to
do
that
even
anonymously,
actually
you
don't
even
need
to
sign
up
for
an
account
if
you
do
have
an
account,
you
can
use
it
with
your
account
and
you
can
save
those
results
and
see
them
over
time.
B
I
can
also
separate
out
my
requests,
so
here
you
can
see
my
scenario
section
that
was
in
the
aw
file
here,
I've
just
broken
out
some
of
that
into
one
request
section
again.
This
is
where,
if
I'm
the
developer
and
I'm
staying
in
my
environment,
I'm
already
working
in
this
editor
writing
code
for
this
app,
maybe
I've
changed
some
really
important
underlying
code.
For
this
page,
all
I
have
to
do
is
change
my
tests
in
real
time
in
the
same
environment,
and
then
I
can
execute
it.
Well,
that's
really
different
right.
That's
that
context.
B
Switching
has
become
a
big
deal
on
continuous
delivery.
The
whole
the
whole
premise
of
continuous
integration
and
continuous
delivery
is
that
we
want
to
find
defects
quickly
and
the
best
way
to
solve
them
is
if
developers
are
still
in
the
mindset
of
when
they
wrote
that
code,
because
they're
still
thinking
about
that
problem
and
its
parameters
and
specific
challenges.
So
we
want
to
keep
the
context
the
same,
and
tourists,
of
course,
can
do
that
right
in
the
same
editor
and
so
I've
broken
out.
B
This
request
file
separate
from
my
execution
command,
and
it's
super
simple
to
work
with
I
can
just
type
clear
this
again
bzzt
execution
and
what
was
it
again,
let's
request
and
then
also
reporting.
So
let's
do
that.
I
can
run
those
through
the
three
together
tortoise
knows
how
to
merge
them,
and
now
it's
opening
up
the
blaze
meter
because
I,
because
I
put
that
command
in
there
tat
to
report
from
blaze
meter.
So
it
looks
like
we
have
some
problems
starting
to
happen
here.
B
In
any
case,
get
to
see
how
that
works,
I'll
show
you
what
a
blaze
meter
report
looks
like
here,
and
so
you
can
see.
Tarus
is
immediately
sending
its
it
stats,
including
100%
errors
up
to
blaze
meter,
but
here's
what
blaze
meter
looks
like,
in
fact,
I
will
log
in
to
my
account
to
show
you
a
better
example
of
this.
B
Here's
a
tourist
test
I
ran
earlier
in
the
week
and
what
it
gives
us
is
all
the
stats
that
matter
for
troubleshooting
the
response
time
or
the
errors
or
the
other
things
that
are
going
on
with
the
performance
test
we
just
ran.
Taurus
will
send
its
data
up
in
real
time
to
our
API
and
then
just
graph
those
out
for
you
again.
B
What's
happening,
you
can,
you
know
drill
into
certain
spikes
if
you
want
to
investigate
a
little
bit
further,
and
you
can
of
course
turn
on
or
off
different
values
like
the
hits
per
second.
Just
for
the
city's
page
or
the
latency
time
is
one:
that's
not
there.
By
default,
we
can
look
at
the
latency
time
average
for
cities
as
well,
whatever
metrics
you
want
to
investigate
or
gather
for
the
performance
troubleshooting
that
you
need
to
do.
B
A
B
B
It
is
a
Python
app,
so
it's
just
pip
install
bzt
and
then
some
great
sample
tests
that
you
can
start
with,
as
well
as
all
the
extensive
documentation
from
the
different
things
that
I've
covered,
but
one
of
the
great
one
of
the
cool
things
about
Taurus
and
I
really
like.
Let
me
know
if
my
my
slides
continue
to
share
here.
We're
still.
B
I
love,
New,
Relic
I
used
to
be
on
the
new
relic
team,
and
it
does
such
an
amazing
job
of
gauging
performance
really
deep
down,
and
especially
in
production.
So
you're
looking
here
at
the
new
relic
browser
tool,
which
is
it
shows
us,
the
different,
endpoints
or
URLs,
are
being
hit
most
frequently
or
some
more
slowly
by
by
users
out
there-
and
here
you
can.
This
is
actual
place,
meter
data
so
about
five
seconds
5.3
seconds
on
our
app
homepage,
which
might
be
something
we
want
to
improve.
B
B
You
can
see
there,
the
concurrency
and
the
duration
and
the
scenario
and
everything
and
that's
going
to
turn
it
into
an
actual
torrance
test
that
I
can
then
run
automatically
so
that
whole
process
query
your
hottest,
URLs,
the
slowest
ones
or
the
busiest
ones
turn
it
into
a
test
and
then
run
it,
and
that
takes
all
of
you.
You
know
the
human
effort
out
of
it.
B
No
developer
may
still
want
to
run
tests
purposefully
and
certainly
for
the
staging
events,
when
these
big
events
and
Valentine's
Day
or
March
Madness
or
the
Super
Bowl
that
are
coming
up.
You'll
want
to
do
a
big
group
test,
but
day-to-day
when
you're
doing
lots
of
commits
and
every
release,
it's
much
cooler
to
just
kind
of
have
tourists
or
have
a
script
that
figures
out.
B
You
know
what
should
I
test
based
on
real-world
stats,
whether
they're
coming
from
New,
Relic
or
Mixpanel,
or
KISSmetrics
or
Google
Analytics
automatically
create
a
test
and
then
go
run
that
test,
so
that
to
me
is
kind
of
the
future
where
we're
headed
a
little
bit
of,
wouldn't
quite
call
it
AI,
but
a
little
bit
of
automation,
magic
to
make
those
tests
a
little
bit
less
hands-on,
and
that's
my
presentation
for
today
any
questions
or
any
further
thoughts.
There's.
B
That
would
be
beyond
me:
I
actually
got
into
openshift
a
little
bit
and
did
not
have
a
time
to
kind
of
become
an
open
shift.
Master
I
learned
I
did
learn
that
there's
a
lot
you
can
do
with
it,
but
I
think
that
tarses
flexibility,
given
that
it's
text
files
and
CLI
it
should
be
pretty
adaptable
and
flexible
to
pretty
much
anything
you
want
to
do
with
it.
B
A
B
Sure
yeah,
absolutely
this
Taurus
can
fold
into
fold
itself
into
any
kind
of
workflow
logic
that
you
have
in
fact,
I
work
with
the
cloudBees
guys
a
lot
and
they're
working
on
very
complex
workflow
drivers,
that
kind
of
branch
off
based
on
certain
logic
and
so
forth,
and
you
can
because
tars
can
piece
together
those
yeah
mole
snippets.
You
can
dynamically
change
things
like
thresholds
or
execution
conditions
or
reporting
conditions
and
just
kind
of
assemble
the
right
pieces
for
the
logic
of
how
your
workflow
needs
to
run.
B
Yes,
I
mean
you
can
do
if
I
understand
what
you're
asking
it
sounds
like
you're
asking
if
you
can
kind
of
what
I,
what
I'd
call
thresholds
where
you,
where
you
are
looking
for
the
average
response
time
over
a
period
of
time
and
then
pause
the
test
or
stop
the
test,
you
can
absolutely
do
that.
You
can
also
use
if
you
get
into
jmeter
a
little
bit
more
deeply.
There
is
an
upcoming
controller
that
will
allow
you
to
pause
ramp
up.
It's
called
the
concurrency
controller.
B
I,
don't
think
it's
how
you
have
to
plug
in,
but
we're
going
to
be
able
to
do
that.
To
all
this.
You
know
driven
by
the
open
source
contributions,
but
yeah
I
mean
you
can
do
that
and
and
whether
you
do
it
with
the
thresholds
to
pause
based
on
that
criteria,
make
some
changes
and
then
see
how
it
proceeds
or
to
stop
or
whatever
absolutely.
A
So
I
have
a
quick
question
for
you.
You
were
demoing
an
open
shift
online,
which
is
the
v2
architecture,
which
is
our
old
gears
and
cartridges
and
some
and
that's
still
in
production.
So
it's
all
good
stuff
and
usable,
but
as
we've
changed
over
to
a
kubernetes
container
based
on
using
dr
does
that
change
anything
in
terms
of
how
we
would
use
tourists.
Have
you
been
doing
any
testing
with
new
architectures.
B
Containers
are
a
great
example
for
that.
Our
great
use
case
for
that
right.
So
you
can
just
add
some
tar
offenders
to
your
docker
file.
Have
that
spin
up
Taurus
and
be
your
execution
engine,
and
sometimes,
if
you're
running
a
large
test.
You'll
need
multiple
execution
engines
because
there's
a
kind
of
upper
limit
for
how
many
threads
or
virtual
users
each
engine
can
run.
So
you
may
want
to
dynamically
spin
up.
You
know
ten
load
generators
if
you're
running
a
very
large
test.
That
would
be
a
really
cool
use
case
for
that.
Well,.
A
A
Yeah,
it's
great
crazy
making
you
mean
it's
really
an
open
ship,
they'll,
pretty
much
run
anywhere,
including
on
bare
metal,
so
we're
lots
of
different
infrastructures
to
deal
with.
So
it's
a
it's
pretty
cool
doing
some
of
this
testing
and
I
really
love
seeing
the
new
relic
integrations.
We
all
do
love
our
new
relic
dashboards
for
everything
they
sort
of
up
the
bar
for
making
things
that
we're
normally
very
boring
and
tedious
beautiful,
as
you
have
with
blaze,
meter
and
your
dashboard,
so
that
that's
pretty
cool
stuff.
So.
B
I
just
want
to
point
out.
We
are
on
the
marketplace
right.
So
if
you
do,
if
you
do
want
to
just
use
blaze
meter,
which
you
can
use
tourist
tests
and
other
tests-
and
if
you
already
you
know
no
J
meter,
you
can
simply
upload
those
tests.
You
can
actually
find
blaze
me
right
in
the
in
the
open
chef
marketplace
there
and
that's
a
kind
of
a
you
know,
one
click
or
to
click
way
to
get
started.
So.
A
B
Love
to
yeah
and
I
think
that
would
be
fun
for
me
to
prep
exactly
like.
We
said
kind
of
create
a
little
bit
more
of
a
complex
load
generation
farm
and
have
it
a
little
bit
a
little
bit
more
dynamic
based
on
what
the
teams
want
to
do
and
in
terms
of
that
workflow.
That
would
be
a
lot
of
fun.
I'd
love
to
do
it
so.
A
B
Think
we
do
I'll
have
to
check
that
might
have
to
be
a
follow
up.
The
the
the
chief
committer
Andre
he's
actually
coming
tomorrow
from
Russia.
He
lives
in
Russia
and
he's
coming
to
visit
us
tomorrow.
So
of
a
better
answer
for
you
that
I,
don't
think
he's
published
anything
up
to
docker
hub
yet,
but
that's
a
good
idea.
We
definitely
need
to
do
that.
So.
A
So
what
we
usually
do
with
these
sessions,
their
common
suite
things
is,
we
will
publish
it
probably
on
Monday
one
with
a
link
to
the
recording.
If
he
tells
you
something
different
drop
me,
a
note
and
I
will
put
a
link
to
it
or
if
he
creates
one
over
the
weekend,
because
you
bought
them
a
lot
of
beers.
Vodka,
vodka.
A
But
you
I'll
add
that
into
the
blog
post
that
we
put
up
on
Monday.
So
that's
me
the
great
thing
so
I
think.
That's
all
the
questions
that
I'm
seeing
this
has
been
a
very
informative
session.
I
really
love
seeing
the
ammo
on
my
screen
again,
it's
near
and
dear
to
my
old
heart.
So
we'll
definitely
have
you
back
to
do.
You
know
the
doctor
eyes
version
of
all
this.
That
was
very.