This page is work in progress document which describes performance tweaks which you can make to get Koha running faster

For rationale about Cache handling in Koha see separate page.

Template Toolkit

Template caching is introduced into Koha with Bug 7511

This improvement is part of Koha 3.8, but you have to add new configuration directive to koha-conf.xml (but see Bug 7533)

 <template_cache_dir>/tmp</template_cache_dir>

Cache module will add directory subtree under that path, so it won't clobber your /tmp with lot of files.

If instead of /tmp or /tmp/koha you choose other directory don't forget to set the ownership to Koha:

 mkdir -p /var/cache/koha/INSTANCE/templates
 chown INSTANCE-koha:INSTANCE-koha /var/cache/koha/INSTANCE/templates

Koha::Template::Plugin::Combine

Error creating thumbnail: Unable to save thumbnail to destination

One of suggestions in Bug 1918 - Minify JavaScript and CSS is to minify JavaScript and CSS. While that does brings us some improvement, even bigger reduction in number of round-trips to server can be achieved using this plugin.

Picture shows reduction from 44 to 31 requests on this search result page which have a lot of requests mostly because of cover images.

Memcache

Memcache will give you performance benefit of sharing cached values between requests. This will give you performance gain (since there is network overhead in requesting values) but will give you huge benefits if you have a lot of concurrent connections. It also allows you to cluster more effectively.

Configuration

Quite confusingly, memcache configuration is picked from koha-conf.xml configuration file.

 <memcached_servers>localhost:11211</memcached_servers>
 <memcached_namespace>koha</memcached_namespace>

Take a look at the about page to know if memcached is correctly configured.

Database

Koha in it's current release uses MySQL.

MySQL tuning

Some of Koha's queries do benefit from occasional index or newer version of database. For example, if you are using MySQL from Debian distribution, upgrading to Percona MySQL server will bring performance benefit, even for same MySQL version.

Adding additional indexes might prove useful, for example for Shelf Browser see http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7886

Koha is heavily dependent on MySQL query cache as shown here:

This will decrease over time as our code gets better in internal caching, but for now, remember to allocate enough space for MySQL query cache.

To tune your MySQL setup you might find useful MySQLTuner-perl.
See also this Koha Tuning Guide

using DBD::Gofer as local SQL query cache

I did some measurements with DBD::Gofer which is network serialisation layer which can introduce local cache with:

 DBI_AUTOPROXY=dbi:Gofer:transport=null;cache=1

This pass SQL query to original database, but cache queries in memory, just like MySQL query cache does.

This has performance impact on generated search page:

 time      DBI
 2.952961  0.713  localhost socket
 3.709371  1.634  Gofer cache
 2.395195  0.996  Gofer with seeded cache
 3.866916  2.659  Gopher+ssh tunnel/1Gb LAN

This are plack numbers, but are useful for estimating performance implact of Gofer itself. It roughly doubles number of perl statements execuited in NYTProf. I also have to re-run them with dropping caches and more samples...

And now numbers from caching layer: we issue 1674 queries of which 927 are unique. That means we are generating double traffic to database so using local caching via DBD::Gofer (which is part of standard DBI install, BTW) might buy you some performance.

plack

plack makes your Koha code persistent in memory, and it makes everything faster. You can still change and reload code on the fly, and it provides nice ways to profile request time, memory usage, DBI query time and module size.

Plack is now considered as stable since Koha version 3.22

profiling

To be written, based on new plack development

Work in progress

Take a look a the 2 omnibus bugs to know the areas the developers are currently working on:

Performance

Contents