From Koha Wiki
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 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)
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
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 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.
Quite confusingly, memcache configuration is picked from koha-conf.xml configuration file.
Take a look at the about page to know if memcached is correctly configured.
Koha in it's current release uses MySQL.
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.
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:
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 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
See also: Plack.
To be written, based on new plack development
See also: Profiling with DevelNYTProf.
Work in progress
Take a look a the 2 omnibus bugs to know the areas the developers are currently working on: