- Koha-devel - lists.koha-community.org

A longer barcode
by Zeno Tajoli 18 Apr '12

18 Apr '12

Hi to all, a library of us ask me to use barcode more long of 20 char. I think I need to change from 'barcode' varchar(20) NOT NULL, to 'barcode' varchar(60) NOT NULL, Clerly there are problems on OPAC and Intranet display (template are organized with a max barcode lenght of 20 chars). But in .pl and C4 perl code ? Is the limit of 20 char only in DB definitions or also in any points of the code? Do you have experience on the topic ? Cheers Zeno Tajoli -- Dott. Zeno Tajoli tajoliAT_SPAM_no_prendiATcilea.it fax +39 02 2135520 CILEA - Consorzio Interuniversitario http://www.cilea.it/disclaimer

2 1

Re: [Koha-devel] Koha performance enhancement overview
by Jared Camins-Esakov 18 Apr '12

18 Apr '12

[Adding koha-devel back in] On Mon, Apr 9, 2012 at 9:37 PM, Ian Walls <koha.sekjal(a)gmail.com> wrote: > I'd be curious if TurboMARC might be a worthwhile compromise: the > extensibility of XML, but easier to process than MARCXML. > It might be worth looking into, but it seems like the amount of work necessary just to test it in a small way would be much to high to justify for idle curiosity (though if anyone feels like doing it, I wouldn't want to discourage them!). Regards, Jared -- Jared Camins-Esakov Bibliographer, C & P Bibliography Services, LLC (phone) +1 (917) 727-3445 (e-mail) jcamins(a)cpbibliography.com (web) http://www.cpbibliography.com/

9 17

Call for News for the April Newsletter
by Daniel Grobani 16 Apr '12

16 Apr '12

Dear Koha Kommunitarians, I'm harvesting news for the April newsletter. Please send me by the 25th anything you think your fellow community members might like to know about. "News" can be as short as a sentence or as long as a paper. I especially encourage you to send me a line or two for the gossip/society column about what you're currently working on. And if you know of a go-live not announced on the list, please be sure to let me know about it. Thanks, Daniel Grobani

1 0

Koha performance enhancement overview
by Ian Walls 16 Apr '12

16 Apr '12

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. 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 - caching tools like memcached or T:T cache Code cleanup - Denesting dependencies - Optimizing SQL queries - Dual database handles (readonly, read/write) - Simplifying code - Minimizing XML parsing 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/) - caching some data client-side (like user preferences) in cookies or localStorage Ergonomics - 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 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. Cheers, -Ian

7 8

Only 7 days until the deadline for submitting your talk for Kohacon12
by Chris Cormack 13 Apr '12

13 Apr '12

If you are thinking about presenting at Kohacon12 at either conference or hackfest, you only have 1 week left to get your abstract in. So please head on over to http://koha-community.org/kohacon12/call-papers/ and submit your talk now. You know you want to :) Chris

1 0

Kohacon12 June 9-11 hackfest
by Frédéric Demians 13 Apr '12

13 Apr '12

Hello, Is there already a program for Edinburgh June 9-11 hackfest? Who will attend? What will be discussed or done? Is some preparation/coordination required? Kind regards, -- Frédéric DEMIANS http://www.tamil.fr/u/fdemians.html

3 2

Bug 5617 - fix-perl-path.pl misses some files - UPDATE
by Bernardo Gonzalez Kriegel 13 Apr '12

13 Apr '12

On a clean install from master (and other versions), the files at the bottom are not updated by fix-perl-path.pl In a case as mine (Centos 5.6, native perl 5.8.8, perl 5.14.1 on /usr/local) this gives a system unusable because you can't change system preferences. Unless of course you fix all files by hand. I think that deserves increase its severity (currently is LOW) Perhaps adding ".pl" to some of these files (and fixing the references) could help to partially solve the problem. [master install] bin/maintenance/borrowers-force-messaging-defaults bin/admin/koha-preferences intranet/cgi-bin/installer/data/mysql/atomicupdate/bug_7284_authority_linking_pt2 (shebang "#! /usr/bin/perl", with space) intranet/cgi-bin/installer/data/mysql/atomicupdate/bug_7284_authority_linking_pt1 (shebang "#! /usr/bin/perl", with space) intranet/cgi-bin/reports/issues_by_borrower_category.plugin intranet/cgi-bin/reports/itemtypes.plugin intranet/cgi-bin/acqui/pdfformat/layout2pages.pm intranet/cgi-bin/acqui/pdfformat/layout3pages.pm intranet/cgi-bin/svc/authentication intranet/cgi-bin/svc/new_bib intranet/cgi-bin/svc/bib_profile intranet/cgi-bin/svc/import_bib intranet/cgi-bin/svc/config/systempreferences intranet/cgi-bin/svc/bib lib/C4/ShelfBrowser.pm misc/translator/translate opac/cgi-bin/opac/unapi [Koha 3.6.4] bin/maintenance/borrowers-force-messaging-defaults bin/admin/koha-preferences intranet/cgi-bin/reports/issues_by_borrower_category.plugin intranet/cgi-bin/reports/itemtypes.plugin intranet/cgi-bin/acqui/pdfformat/layout2pages.pm intranet/cgi-bin/acqui/pdfformat/layout3pages.pm intranet/cgi-bin/svc/authentication intranet/cgi-bin/svc/new_bib intranet/cgi-bin/svc/bib_profile intranet/cgi-bin/svc/config/systempreferences intranet/cgi-bin/svc/bib lib/C4/ShelfBrowser.pm misc/translator/translate opac/cgi-bin/opac/unapi [Koha 3.4.7] bin/maintenance/borrowers-force-messaging-defaults bin/admin/koha-preferences intranet/cgi-bin/reports/issues_by_borrower_category.plugin intranet/cgi-bin/reports/itemtypes.plugin intranet/cgi-bin/acqui/pdfformat/layout2pages.pm intranet/cgi-bin/acqui/pdfformat/layout3pages.pm intranet/cgi-bin/svc/authentication intranet/cgi-bin/svc/new_bib intranet/cgi-bin/svc/bib_profile intranet/cgi-bin/svc/config/systempreferences intranet/cgi-bin/svc/bib lib/C4/ShelfBrowser.pm misc/translator/translate opac/cgi-bin/opac/unapi Bernardo -- Bernardo Gonzalez Kriegel bgkriegel(a)gmail.com

1 0

SVC templates
by Ian Walls 11 Apr '12

11 Apr '12

Right now, the few web services we have all create their XML output using XML::Simple. This is not the fastest parser in the world, so I've been looking to minimize/remove it's usage. Looking at it in /svc got me thinking: perhaps we should be using T:T to generate our web services output instead. This would have all the advantages of T:T, and allow us to reuse common portions text. I think the templates would live in koha-tmpl/svc-tmpl/prog/en. From there, we could break down by output language (XML, JSON, etc), so our web services could be fully customizable in terms of output format (without having to reinvent the script, or provide long nasty if/elsif conditionals). If we put this in place now for the few /svc scripts we have, it would be a good test for the practicality of this, and if it works, could be a practice to continue forward (with several working examples). Thoughts? -Ian

2 3

combining and minification of javascript and css
by Dobrica Pavlinusic 07 Apr '12

07 Apr '12

I would like to address this one as part of performance work. We have existing bug for this, but I'm sending also this to list to get wider feedback. http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=1918 I found https://github.com/jshirley/Plack-Middleware-ComboLoader which got me pushed in right direction, but in the end I decided to implement Koha::Template::Plugin::Combine because it turned out that it's easier if we can use combining and minification together. Changes are available at: https://github.com/dpavlin/Koha/compare/dpavlin:plack...dpavlin:bug_1918-co… Minification alone doesn't buy us much: OPAC search: minify js 334974 -> 311553 93.01% minify css 148277 -> 133128 89.78% intranet search: minify js 382102 -> 362172 94.78% minify css 134754 -> 123771 91.85% But combining JS and CSS files together saves us round-trips to server: OPAC 32 -> 20 requests intranet 27 -> 13 requests I would love to hear your feedback on this. -- Dobrica Pavlinusic 2share!2flame dpavlin(a)rot13.org Unix addict. Internet consultant. http://www.rot13.org/~dpavlin

3 2

RFC: Koha::Persistent - for plack and general performance
by Dobrica Pavlinusic 07 Apr '12

07 Apr '12

I would like to propose new module which would keep track of all persistant values for rest of Koha code. We are currently using following caching strategies: 1. our $cache variables 2. memoize (in-memory) 3. memoize_memcache (in memcache only) As opposed to C4::Cache* which never got implemented in all code, I propose new Koha::Persistant[1] module which provides methods for caching designed in such a way to reduce code size in modules which use it, see [2] for authorised_value and [3] for marc_subfield_structure 1: https://github.com/dpavlin/Koha/blob/plack/Koha/Persistant.pm 2: https://github.com/dpavlin/Koha/commit/6cd524f99b1bbc03eb1ad7110b0b97016569… 3: https://github.com/dpavlin/Koha/commit/70a414d93bd0ae309e9d6097ea87a17e3341… I implemented just two function to see if this approach makes sense. I started with DBI Profile to track down same or similar queries and try to make nice API which satisfies requirements above. It also provides $Koha::persistant::stats which can be used to track hit/miss ratio of cache so we can easily evaluate caching impact. There is even Plack development panel, see "Persistant" at 1:01-1:30 http://blog.rot13.org/koha/koha-plack-debug.ogv Koha::Persistant should also include invalidation functions for all structures which it addresses, so they can be inserted in corresponding places to provide correct values when changing data directly in database. This will be done for existing functions before I submit it to Koha to keep everything clean from the start. It would also provide memoize function, which would replace memoize_memcahe and provide in-memory caching together with memcache, but still cache in memory if memcache isn't available. As shown in http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7879 we do get performance benefit from it, since our code is using MySQL query cache a lot which means we are quering for same data over and over again, see: http://wiki.koha-community.org/wiki/Performance#MySQL_tuning In first phase, I would propose to reset in-memory cache and memoize functions on each request to be consistant with CGI implementation and side-step caching bugs which we see with plack right now. This style of implementation will require large patches which touch many different places of code at same time. I think that 3.10 relese cycle is good way to introduce this changes, but I would need commitment from developers to Sign-off and QA patches fast, since those changes will be hard to keep up with development. p.s. I will create RFC wiki page after discussion, but I would really need some response before continuing down this path. -- Dobrica Pavlinusic 2share!2flame dpavlin(a)rot13.org Unix addict. Internet consultant. http://www.rot13.org/~dpavlin

5 12