[Koha-devel] Koha performance enhancement overview

Dobrica Pavlinusic dpavlin at rot13.org
Mon Apr 9 19:03:06 CEST 2012


On Mon, Apr 09, 2012 at 09:54:35AM -0400, Ian Walls wrote:
> Everyone,
> 
> 
> I was doing some thinking this weekend about the overall goal of making
> Koha perform faster.  We're approaching this from several different angles,
> so I thought it might be a good idea to come up with a summary of all the
> various methods we could use to speed Koha up.

I submitted talk proposal for KohaCon hackfest in which I plan to cover
similar topics. I allmost feel like you wrote my talk overview :-)

> Tuning & Hardware (http://wiki.koha-community.org/wiki/Koha_Tuning_Guide)
> 
>    - Hardware selection guide (how much CPU, RAM and disk to run Koha on)
>    - Tuning the operating system
>    - Tuning Apache
>    - Tuning MySQL
> 
> Performance tools
> 
>    - Alternate, Persistent Perl interpreters, like Plack/PSGI or
>    mod_perl/FastCGI (http://wiki.koha-community.org/wiki/Plack)
>    - Alternate webservers like Nginx or Starman

Starman is part of plack if you want to run multiple processes. However,
you would like to put some web server or http proxy in front of it, at
least for static content so you don't need to run perl code for it.

>    - caching tools like memcached or T:T cache

T:T cache is so essential, that we should make it enabled as default,
and not as on option.

> Code cleanup
> 
>    - Denesting dependencies
>    - Optimizing SQL queries
>    - Dual database handles (readonly, read/write)

I'm missing caching here. I did experiments with memoizing, I just
haven't had time to rebase them to current master and re-run benchmarks
again. With cache, spliting handles and replication becomes allmost
non-issue :-)

>    - Simplifying code
>    - Minimizing XML parsing

I had one patch with this which uses marc instead of marcxml from
biblioitems to provide huge performance improvement:

http://git.rot13.org/?p=koha.git;a=commitdiff;h=a18a7f709447cccf617e8fa5b545d6a82606deeb;hp=095b0af09d6cbc2bf579ba6ae353b9715b035118

(it needs cleanup, rebase and probably own bug)

> Network latency
> 
>    - AJAX calls for key functions like circ (cheaper to send/receive than
>    full page loads)
>    - Minifying JS and CSS (
>    http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=1918)
>    - CSS sprites (css-tricks.com/css-sprites/)

I write Moose based web framework a while ago, which had this feature:

http://svn.rot13.org/index.cgi/Frey/view/trunk/lib/Frey/Web/CombineImages.pm

It turns out that it really pays off for icons or other more-or-less
fixed sized assets which are often requested. I could rewrite it into
Template Toolkit plugin, I guess :-)

>    - caching some data client-side (like user preferences) in cookies or
>    localStorage
> 
> Ergonomics

To be honest, erfonomics didn't cross my mind, but it's a important point!

>    - Fewer clicks to do common actions
>    - Display important info more prominently
>    - Preferences to customize to individuals' workflows
> 
> 
> Now, here's the question:  which of these techniques will net us the
> biggest boosts for the least effort?  We've got lots of great work on Plack
> so far, but would figuring out the perfect MySQL tuning settings be easier
> and give us a similar performance enhancement (I don't know, just using as
> an example)?  Some of these are of course inter-related; doing code cleanup
> and denesting would make it easier to do AJAX calls or use mod_perl.

I would vote for accessor simplification and memoizing as smallest
changes which biggest impact. In fact, that's why I proposed myself as
performance bug wrangler in the first place.

> I should probably dump this into a wiki page, but I wanted to raise the
> issue on-list first.  Does anyone have any data that we could use to
> determine what above is low-hanging fruit, or what will get the biggest
> gains?  We're lucky in this community in that we have many, many kinds of
> expertise, so we're not limited to pursuing any one course at a time, but
> having a coordinated effort would help us reap more tangible benefits
> sooner.

I started

http://wiki.koha-community.org/wiki/Performance

as dumping ground for topics which I would like to cover at KohaCon.
I think that this breakdown would be great addition to it :-)

-- 
Dobrica Pavlinusic               2share!2flame            dpavlin at rot13.org
Unix addict. Internet consultant.             http://www.rot13.org/~dpavlin


More information about the Koha-devel mailing list