Koha Tuning

A recent post on koha-devel list listed a number of possible tweaks in order to manage performance enhancement.  The final list is displayed here.

• Mysql config:  Increased innodb buffer pool size to 10000M (was 1024M); followed mysqltuner recommendations to set join_buffer_size (32M), query_cache_limit (16M), query_cache_size (16M), tmp_table_size (8M) and max_heap_table_size (8m).  Mysqltuner still suggests more for those values, but the speed issue seems to be resolved so I'm not going to worry about it for now.  The max amount of system memory it can currently use is 85%.
• Moved the zebra db to another drive
• Optimized mysql tables; mysqltuner reported that one table was fragmented.
• Applied Mason's apache2 caching config recommendations
• Storing session files on a ramdisk (/dev/shm) (Dobrica's suggestion)
• mod_perl --Kyle got it to work by adding the following to httpd.conf:
               <Files *.pl>
         SetHandler perl-script
         PerlResponseHandler ModPerl::PerlRunPrefork
         PerlOptions +ParseHeaders
         PerlSendHeader On
         Options +ExecCGI
         </Files>
  
         PerlWarn On
         PerlRequire /home/koha/startup.pl
  

a recent conversation with Kyle Hall has confirmed that the above settings do not work to get mod_perl working on a production Koha install.  I can confirm that issues still arise with it  - IW

RFC 3.4 is mentioning mod_perl as a way to do this.

BibLibre is doing research on Plack which is just a more general approach. Since it could then be used in fcgi or mod_perl mode.

It is quite unharmful to the code. Just need to install Plack (cpanm Task::Plack and some Debug facilities cpanm Plack::Middleware::Debug). Then you can edit that file to use your git install. [[]]

#!/usr/bin/perl

use Plack::Builder;

use Plack::App::CGIBin;

use Plack::Middleware::Debug;

use lib("/home/koha/gitosis-admin/am123/");

use C4::Context;

use C4::Languages;

use C4::XSLT;

use C4::Branch;

use C4::Category;

my $app=Plack::App::CGIBin->new(root => "/home/koha/gitosis-admin/am123/opac");
builder {
enable 'Debug', panels =>
[ qw(Environment Response Timer Memory),
[ 'DBITrace', level => 2 ]
];
;
enable 'StackTrace';
mount "/cgi-bin/koha/" => $app;
};

You will need to use one more patch in order to make advanced search work (it just filters empty parameters in order not to pas it over to the buildQuery).

you can then launch

KOHA_CONF=/path/to/your/etc/koha-conf.xml  plackup /home/koha/gitosis-admin/am123/koha.psgi

You can also set DEBUG to 1 if you want

DEBUG=1 KOHA_CONF=/path/to/your/etc/koha-conf.xml  plackup /home/koha/gitosis-admin/am123/koha.psgi

And you are set. You can play on your port localhost:5000

This has been done only for OPAC. (It is more vital as intranet for public library and demands more attention).

But it could/should be done for intranet too.. But then, work would be heavier.

It should be noted that search is working. But all the static content is not embedded. It has to be coped by nginx configuration or apache configuration. Here is for apache : 

  

<VirtualHost opac-plack>     

        ServerName opac-plack
         DocumentRoot /path/to/koha/koha-tmpl

         ProxyRequests off
      <Location /cgi-bin/koha/>

       Rewriteengine On
       ProxyPass http://localhost:5000/cgi-bin/koha/
       ProxyPassReverse http://localhost:5000/cgi-bin/koha/
      </Location>
       ExpiresByType image/gif "modification plus 5 hours 3 minutes"
       ExpiresByType application/javascript "modification plus 5 hours 3 minutes"
      ExpiresByType text/css "modification plus 5 hours 3 minutes"
      </Virtualhost>

But it can be done.

But with Plackup and the tools it provides, on every page, we can profile the memory usage. And it is quite heavy. For simple Opac-main.pl memory usage goes up to 30 Mo. DBI::Trace is also displaying all the mysql transactions done to display the page... And there are MANY.

So this tool could be of great help in order to find contention problems and improve the memory print of Koha pages.

Hopes that helps.

An important thing to note, is that with Plack, or any kind of persistence, we need to add code to flush things like systempreferences, which now persist. IE changing a systempreference in the db, currently requires the plack code to be restarted before the change shows up. Chrisc 23:17, 6 July 2010 (UTC)