►
From YouTube: Evaluating and Improving Koha Performance
Description
Presenter:
- Nick Clemens (ByWater Solutions)
Slides:
- https://docs.google.com/presentation/d/1clD1cqtqgSGcj1xD57cMhyCH3tmMfUBwCn_gU9oB7V4/edit?usp=sharing
A
So
I
am
Nick
lemons
I'm,
one
of
the
developers
at
buy
water
I
have
been
a
cohort
developer
for
several
years.
I
have
been
a
former
release,
maintainer
I'm
on
the
QA
team
and
I
refer
to
myself
as
a
sonic
screwdriver,
which
means
you
can
point
me
at
a
problem
and
I'll
make
a
lot
of
noise
and
something
will
happen.
I,
don't
know
what.
A
So
basically,
I
just
want
to
talk
a
little
bit
about
the
performance
of
koha
and
what
we've
been
doing
with
that
I've
been
working
on
this.
For,
like
the
past
year,
we've
had
a
lot
of
newer
libraries,
larger
libraries
and
libraries
that
have
been
on
koha
for
a
long
time.
As
that
happens,
we
kind
of
see
new
issues
where
somebody
with
a
lot
of
data
or
somebody
with
a
lot
of
historical
data,
can
see
things
get
a
little
bit
slower.
A
Sorry,
so,
basically,
there's
there's
really
three
steps
that
we
kind
of
go
through
when
we're
talking
about
looking
at
color
performance.
First
of
all,
you
have
to
identify
the
issue.
You
know
what
module
is
it
in
koha?
What
role
does
it
play
and
kind
of
what's
happening?
There
two
pinpoint
the
bottleneck.
A
What
is
going
on
in
the
code
what's
happening
there?
That's
you
know
slowing
it
down,
and
what
do
we
really
need
the
code
to
put
output
in
the
end
and
three
is
proposing
a
remedy
where
we
have
to
balance
the
performance
with
coding
guidelines
and
with
the
user
needs
so
tldr.
The
three
things
that
I'm
really
going
to
talk
about
are
using
night
Prof
and
Benchmark,
which
are
Pearl
tools
that
help
you
evaluate
how
fast
your
code
is
running
and
see
what's
going
on
under
the
hood.
A
The
second
is
using
test
Builder
test.
Builder
is
a
technical
piece
of
software
that
we
use
within
koha
in
our
tests
to
create
objects,
but
we
can
use
it
here
when
we're
testing
performance
to
kind
of
fill
in
our
our
test,
co-hosts,
so
that
we
have
things
to
to
test
and
three.
It's
just
that
when
we're
thinking
when
we're
developing
koha
and
we're
working
on
koha,
we
need
to
think
big.
A
So
the
first
step,
of
course,
is
identifying
the
issue.
There's
a
couple
things
that
can
happen
here.
It
can
be
something
where
we
get
a
report
from
the
library.
This
can
either
come
from
the
staff
or
the
patrons,
or
it's
something
that
we
just
happen
to
see
on
bugzilla
now,
I,
don't
know
if
anyone
everyone
out
there
is
registered
on
bugzilla
we're
going
to
talk
about
that
later.
A
But
it
is
important
that
when
you
have
these
performance
issues
to
file
them
on
bugzilla,
that's
the
way
that
you
can
let
all
the
developers
out
there
know-
and
you
can
kind
of
too
if
you
promote
that
bug,
find
out
the
other
users
who
experience
this.
So
we
can
see
if
it's
kind
of
a
widespread
issue
or
if
it's
something
narrow
to
your
library
and
something
that
you
use.
A
The
second
way
that
we
find
things
is
when
developers
find
them
through
what
I
like
to
call
spelunking,
which
is
either
when
we're
testing
other
bugs
we'll
kind
of
just
see
something
and
we'll
say:
hey
we
can
make
that
better
or
when
we're
writing
a
new
code.
We
we
need
to
kind
of
keep
this
in
mind
and
we
can
end
up
seeing
other
things,
as
we
add
our
new
code
to
the
system.
A
A
A
When
you
have
this
longer
one,
you
can
kind
of
see,
then
all
the
little
pieces
and
which
parts
of
that
take
up
the
most
time.
This
is
a
really
useful
tool
for
developers
and
I
highly
encourage
using
it,
because
it
helps
you
know
how
much
time
you
can
actually
save
by
your
improvements.
I
personally
know
that
I
have
occasionally
spent
a
lot
of
time,
improving
performance
on
something.
That's
this
section.
A
A
This
is
just
a
second
view
of
that.
In
case,
you
don't
want
to
look
at
the
Flames,
which,
of
course
you
do,
but
if
you
need
a
more
readable
view,
this
is
the
same
output,
and
it
just
shows
you
here.
The
exclusive
time
in
the
inclusive
time
spent
in
every
routine
exclusive
time
is
how
much
time
was
spent
literally
in
that
code.
Inclusive
time
includes
all
of
the
subroutine
calls
that
it
makes.
A
What
I
like
about
this
code
is
that's
really
easy
to
adjust.
It's
real
easy
using
test
Builder
to
just
tell
it
to
make
a
hold
and
place
a
hold,
and
you
can
tell
it
to
place
a
hold
for
50
patrons
100
patrons
a
thousand
patrons,
because
until
you
do
this,
sometimes
things
look
really
good
and
making
big
data
makes
it
a
lot
bigger
to
see.
What's
going
on.
A
A
So
we
need
to
consider
the
real
world
sources.
Consider
the
history.
The
longer
a
library
is
around
the
more
like
statistical
data
they'll
have
in
the
system
and
sometimes
when
we're
developing
a
new
feature.
We
don't
see
that,
or
we
haven't
planned
ahead
to
have
all
of
that
kind
of
in
there
and
loading
all
of
that.
A
A
A
So
there
may
be
more
than
one
way
to
crack
an
egg
a
lot
of
times
developers.
We
are
sometimes
referred
to
as
lazy,
which
is
definitely
not
fair.
However,
we
will
reuse
code
if
there
is
a
routine
out
there.
That
will
give
us
the
data
that
we
need
sometimes
we're
just
going
to
go
ahead
and
reuse
that
well,
that
can
be
problematic
if
we're
using
it
in
a
different
way
that
it
was
intended.
A
Recently,
there
was
a
performance
issue
found
with
the
budget
drop
downs
on
one
of
the
pages
where,
in
order
to
load
the
budget
drop
down,
we
were
calling
a
routine
that
went
and
got
all
the
budgets
in
the
system
and
then
calculated
how
much
was
spent
on
each
budget
and
then
calculated
how
much
was
received
on
each
budget
and
built
all
these
totals
to,
in
the
end,
throw
away
half
the
data
and
just
show
you
a
list
of
budget
names.
So
sometimes
it's
it's
kind
of
that.
A
Looking
back
on,
what
have
we
done
and
seeing
what
we
need
to
do
next,
maybe
don't
sometimes
we
have
code
that
is
doing
things
that
we
just
don't
need
to
do
and
I'm
going
to
mention
something
that
I'm
going
to
bring
up
again
later,
but
there's
a
feature
in
koha
that
allows
you
to
renew
a
patrons
book.
If
there
are
holes
on
the
book,
but
those
holds
can
be
filled
for
other
items.
A
A
So
that's
a
quick
way
to
kind
of
gain
some
performance
there.
Cash
is
King.
Caching
has
become
a
big
issue
in
koha.
We've
been
implementing
this
everywhere.
To
kind
of
make
a
lot
of
the
values
come
up
a
lot
faster.
If
we
can
load
things
once
save
them
and
reuse
them,
it
really
can
enhance
our
performance
time
overall.
A
Give
me
give
me
more
consider
prefetching,
really
I,
just
wanted
an
excuse
to
put
Brittany
my
slides,
everybody
I'll
admit
it:
okay,
there.
She
is,
but
it's
true
that
a
lot
of
times
too.
What
we
find
is
that
there's
code
that,
where
we've
added
new
things
to
the
display,
as
we've
added
them,
to
display
we've
just
kind
of
called
them
from
the
database
again.
A
Instead,
if
we
call
everything
at
once,
we
can
make
things
run
a
lot
faster,
sweat,
the
small
stuff
we
we're
working
on
a
problem
with
the
holds
page
being
slow.
Where
we
found
that
libraries
who
had
a
ton
of
holds
on
one
book,
it
was
very
slow
and
there
were
some
other
things
to
tackle.
But
one
of
the
things
that
I
found
at
one
point
was
that
the
holds
page
when
we
were
loading.
A
This
is
something
that
Martin
Ren
voice
at
ptfs
Europe.
Actually,
he
wrote
this
little
subroutine
here
that
I
use
all
the
time.
What
this
will
do
is
it
will
spit
out
kind
of
different
rates
of
how
fast
each
bit
of
code
runs.
So
it
will
tell
you,
if
you
put
in
there
four
different
ways
to
do
the
same
thing
it
would
at
the
end,
will
give
you
a
list
of
how
fast
each
one
of
those
were.
A
A
Where
I
just
looked
at
the
performance
wrong,
I
was
trying
to
see
if
using
a
specific
method
in
cohab
was
fast
and
so
I
called
it
a
bunch
of
times
on
the
same
biblio.
Well,
if
you
do
that,
yeah,
it's
slow,
but
it
turns
out
that
if
you
use
it
in
a
real
world
example
where
you
call
it
once
for
a
row
of
data
that
you're
going
to
kind
of
iterate
over
so
you're
looking
at
a
bunch
of
biblios,
then
it's
actually
faster.
A
So
this
is
just
a
cool
tool
for
developers
out
there
once
you've
done
this
wait
again
and
again,
you're
going
to
need
to
repeat
your
tests.
As
you
kind
of
look
at
the
code
evaluate
perform,
it
then
you're
going
to
need
to
test
it.
It's
a
slow
process.
It
takes
a
lot
of
time
to
put
in
to
reduce
the
time
that
you're
going
to
get
out.
A
And
we
keep
doing
it
once
you've
done
a
little
bit.
You've
found
one
place
that
you
can
improve.
It
then
I
go
back
to
the
flame
graph
check
the
Flames
again
see
what
I've
shrunk
see
where
I
can
shrink
it
again
and
repeat
now.
These
are
just
some
useful
tips
for
developing
in
koha
break
it
down.
This
is
just
a
funny
webcomic
that
I
love.
The
important
thing
is
to
make
small
steps
when
we're
submitting
code
to
call
when
we're
making
changes
to
koha.
A
It's
very
important
to
try
not
to
redo
the
performance
of
the
Page
by
rewriting
the
entire
thing
in
one
go.
If
you
do
that,
it's
great,
but
it's
going
to
be
hard
to
move
forward
just
because
it
can
be
hard
to
understand,
bring
your
receipts
when
you're
testing
the
performance
make
sure
that
you
show
people
the
benchmarking.
You've
done
the
time
that
it
hits
that
you
have
saved
so
that
they
can
recreate
it
so
that
they
can
test
it
and
they
can
know
whether
it's
worth
it
or
not.
A
Is
that
making
things
faster?
We
can
do
that,
but
sometimes
we
need
to
pay
attention
to
the
needs
of
the
user.
So
before
I
mentioned,
where
renewals,
if
they're,
if
a
user
is
over
the
renewal
limit,
we
don't
need
to
check
the
hold
ability.
However,
it
turns
out
that
a
lot
of
libraries
want
to
know
that
the
book
is
on
hold.
A
They
want
to
know
if
they
can
over
not
override
the
holds,
but
they
can
override
the
renewal
limits,
and
so,
while
we've
made
it
faster,
we
haven't
actually
improved
the
performance
for
users,
because
we
have
taken
away
data
that
they've
relied
upon.
So
it
can
be
a
tricky
thing.
Who
is
the
boss?
Here?
It
is
the
users
developers
we
can
want
to
do
whatever
we
can
to
make
it
faster,
but
if
it
doesn't
help,
there's
not
much
point
to
it.
B
A
The
more
that
we
you
work
on
performance
in
koha,
the
more
it
starts
to
become
part
of
your
mindset.
You
remember
that
this
is
what
you
need
to
work
on
and
as
we
develop
new
things,
we
can
keep
it
in
mind
that
we
need
to
think
about
these
big
data
I.
Personally,
a
lot
of
developments
that
are
when
I
work
on
them
I
will
load
about
30
000
books
into
my
test
environment,
which
is
not
a
lot
compared
to
many
of
the
libraries
out
there.
A
B
Also
I'm,
not
sure
if
this
would
work
in
your
case,
but
whenever
I'm
working
on
something
like
export
of
data
or
trying
to
put
together
exported
data
into
a
bibliography,
I,
always
doing
a
version,
a
version,
B
version
and
save
everything
because
it
comes
sometimes
having
something
through.
Therefore,
Generations
back
really:
oh,
that's.
Where
I
went
wrong.
One
project
I
was
working
on
I
got
down
to
version
V
version
W.
C
A
Okay,
the
URL
is
one
of
the
most
important
bits
of
us
for
us.
Koha
generally
tends
to
be
very
very
static
with
their
URLs,
so
if
you
have
the
actual
URL
that
you
went
to,
that
is
an
enormously
helpful
in
letting
us
know
where
you're
at
in
Co-op
screenshots.
When
you
take
a
screenshot,
if
you
screenshot
the
whole
thing,
the
browser
bar
I
mean
nothing
that
you
don't
want
to
share.
A
If
you
have
tabs
open,
you
know
move
it
to
its
own
tab,
but
if
you
can
capture
the
whole
browser
just
so,
we
can
kind
of
see
everything
about
the
URL.
What's
going
on
on
the
web,
page
kind
of
details
like
that
help
us
find
where
that
problem
is
the
other
thing
that
is
very
helpful,
is,
if
you
have
noticed
a
performance
decrease
or
something
changed.
A
D
So
Nick
I
have
a
question
for
you
and
I
think
this
will
probably
circle
around
back
to
what
you
had
talked
about
at
the
very
beginning.
But
how
can
people
what
what
is
the
best
way
for
people
to
talk
about
these
things
with
you
is
it
is
it
you
know?
Are
you
waiting
for
just
something
to
break
or
or
is
there
a
place
that
you
would
prefer
people
to
insert
themselves
get
involved
in
try
and
notice
these
things
before
they
hit
production.
A
A
A
Irc,
the
developers
were
all
usually
present
there,
as
well
as
the
rest
of
the
community,
is
there
and
on
bugzilla,
we'll
talk
about
more
in
the
community
involvement,
but
there
is
on
bugzilla,
there's
also
a
votes
feature,
and
while
that's
not
a
hundred
percent
reliable
voting
for
something
doesn't
guarantee
you're
going
to
get
it
the
developers,
we
do
try
to
look
at
that
and
sort
bugs
buy
those
votes
to
see
what's
important
to
people
in
the
community.
Does
that
answer
the
question.
D
Yeah
I
I
think
too,
with
getting
involved
in
it.
You
know,
there's
only
so
much
you
can
do
in
the
testing
environment
because
you're
not
putting
it
against
a
real
world
data
or
your
real
world
workflows,
because
you're,
not
necessarily
the
person
that
does
the
stuff
on
the
circulation
end
or
the
cataloging
end.
But-
and
you
kind
of
you
might
have
a
general
sense
of
what
to
do
just
to
get
it
to
do
its
thing.
But
you
don't
know
all
the
the
little
things
that
your
staff
see
every
day
in
production.
A
We
were
just
talking
to
Rhonda
earlier
about
a
potential
development
in
the
Acquisitions
and
as
I
started
to
suggest
things.
I
was
like
wait.
Wait!
Wait.
You
tell
me
the
workflow
you
want,
because
the
last
thing
you
want
is
for
the
developers
to
decide
the
workflow,
because
we
tend
not
to
think
in
the
same
way
that
other
people
do
a
lot
of
things
that
seem
very
clear
and
straightforward
to
us.
They
don't
seem
that
way
to
the
user.
A
That's
Scott
coverman.
He
also
draws
a
comic
called
snake
in
and
bake
or
snake
and
bacon
snake
and
bacon,
which
I
highly
recommend,
but
it's
basically
it's
just
Picasso
yelling,
angrily
at
things
and
saying
he's:
gonna
break
them
down
into
little
cubes
and
then
at
the
end,
there's
of
course
A
Duck
singing
to
him
crooning
to
him,
while
fairies
Rock
him
to
sleep,
singing
I'm
gonna
knock
him
down
into
little
cubes.
E
I've
got
what
might
be
a
leading
question,
so
you
know
how
many
of
the
people-
maybe
this
is
a
question
for
the
people
in
the
room.
How
many
of
you
are
Librarians
that
work
in
a
library
like
checking
books
in
checking
books
out?
You
know
helping
people
with
the
reference
desk
doing
cataloging.
How
many
of
you
are
do
that
kind
of
work,
and
so
how?
Many
of
you
check
bugzilla
regularly.
E
So
would
there
maybe
be
a
good
time
at
this
conference
when
somebody
could
talk
about
you
know
ways
for
librarians
to
better
connect
with
support
companies
and
with
bugzilla,
like
maybe
a
time
on
Thursday
at
9
00
a.m
in
the
morning,
I
think
there
would
be
would
maybe
Jesse,
Kelly
and
Nick
all
be
able
to
address
that.
At
that
time
we
will
previews.
E
Conference
back
at
the
beginning
of
the
pandemic
is
I.
Think
one
of
the
best
things
that
I
think
one
of
the
biggest
stumbling
blocks
between
Librarians
and
koha
is
that
the
people
that
actually
do
the
work
in
libraries
sometimes
don't
communicate
well
with
the
people
that
write
the
software,
the
people
that
develop
the
software,
sometimes
there's
a
disconnect
there
and
I
think
just
being
able
to
learn
how
to
better
interact
with
bugzilla
and
how
to
talk
to
the
developers
and
how
to
communicate.
E
You
know
it
I
think
it's
one
of
the
best
ways
to
get
involved
in
the
koha
community
is
to
and
to
make
koha
better
is
to
try
to
open
those
lines
of
communication,
and
so
a
program
on
Thursday
at
9
00
a.m.
About
how
to
get
more
involved
in
the
community
is
something
that
everybody
could
really
benefit
from.
So
thanks,
Nick.
Thank
you.
George.