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=a18a7f709447cccf617e8fa5b545... (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@rot13.org Unix addict. Internet consultant. http://www.rot13.org/~dpavlin