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

Zebra hyphen truncating search
by David Cook 05 Feb '15

05 Feb '15

Hi Colin! I stumbled across an email you sent to the Indexdata Zebralist in 2013: http://lists.indexdata.dk/pipermail/zebralist/2013-August/002576.html Were you ever able to solve those problems? Also, what version of Zebra were you running? I've noticed this problem with Zebra using 2.0.59, but I haven't been able to produce it using Zebra 2.0.47. I had the exact same configuration files, MySQL database, and Zebra indexes. Here's an example: 2.0.59: Z> f UPA-CE14060101 Sent searchRequest. Received SearchResponse. Search was a success. Number of hits: 12325, setno 1 SearchResult-1: term=UPA cnt=12325 records returned: 0 Elapsed: 0.021128 2.0.47: Z> f UPA-CE14060101 Sent searchRequest. Received SearchResponse. Search was a success. Number of hits: 1, setno 3 SearchResult-1: term=UPA cnt=12325, term=CE14060101 cnt=1 records returned: 0 Elapsed: 0.015657 -- It looks like the packages in Debian 7 and Ubuntu 14.04 are stuck back at Zebra 2.0.44, which is from 2010. However, Indexdata apparently has newer deb packages for both Debian and Ubuntu: http://ftp.indexdata.dk/pub/zebra/. In fact, the server I'm having problems with appears to have installed Zebra 2.0.59 using the following "/etc/apt/sources.list.d/indexdata.list" pointing to "deb http://ftp.indexdata.dk/debian squeeze main". I'm guessing that you were using a Zebra version that was higher than 2.0.47? Possibly a deb package installed from Indexdata's repos? I know Tomas has had good luck contacting Indexdata folk. maybe he has some ideas about how to find a solution to this issue? David Cook Systems Librarian Prosentient Systems 72/330 Wattle St, Ultimo, NSW 2007

3 4

Re: [Koha-devel] Zebra hyphen truncating search Part Deux
by David Cook 04 Feb '15

04 Feb '15

Robin just pointed out that Debian Jessie (8) will be switching to 2.0.59 and I noticed that Ubuntu Vivid (15.04) will as well. That means that Koha package installs that use ICU on these newer OSes will start running into this problem as well. (Actually, most newer OSes will have this issue. OpenSuse 13.2 released in November 2014 is using 2.0.59.) So... that's not good. We first ran into this problem because of a barcode search "ABC-12345" was returning all barcodes that started with "ABC". However, you'll run into this problem for a lot of keyword and title searches. For instance "Mont-Royal" will return all records containing "Mont". Note that this is only for ICU. If you're using CHR, "Mont-Royal" will just get you records that have "Mont" and "Royal" in them (since Zebra/YAZ breaks on hyphens when using CHR character mapping). Anyway, I've sent an email to Indexdata, so I'm going to try pursuing this with them as much as possible... David Cook Systems Librarian Prosentient Systems 72/330 Wattle St, Ultimo, NSW 2007 > -----Original Message----- > From: Colin Campbell [mailto:colin.campbell@ptfs-europe.com] > Sent: Tuesday, 3 February 2015 8:03 PM > To: David Cook > Cc: 'Colin Campbell'; koha-devel(a)lists.koha-community.org > Subject: Re: Zebra hyphen truncating search > > On Tue, Feb 03, 2015 at 05:16:05PM +1100, David Cook wrote: > > Hi Colin! > > > > > > > > I stumbled across an email you sent to the Indexdata Zebralist in 2013: > > http://lists.indexdata.dk/pipermail/zebralist/2013-August/002576.html > > > > > > > > Were you ever able to solve those problems? > > I think its still the case. It can be further complicated by what the settings in > the system are and how Search.pm interprets them in constructing the > search. Especially the relevancy options. > > > > Also, what version of Zebra were you running? I've noticed this > > problem with Zebra using 2.0.59, but I haven't been able to produce it > > using Zebra 2.0.47. I had the exact same configuration files, MySQL > > database, and Zebra indexes. Here's an example: > It would be the current releases from indexdata on Debian and also built > from source on Fedora. The indexdata debian packages track the source > closely. > > Cheers > Colin > > -- > Colin Campbell > Chief Software Engineer, > PTFS Europe Limited > Content Management and Library Solutions > +44 (0) 800 756 6803 (phone) > +44 (0) 7759 633626 (mobile) > colin.campbell(a)ptfs-europe.com > skype: colin_campbell2 > > http://www.ptfs-europe.com

1 0

Dev meeting February 5
by Tomas Cohen Arazi 02 Feb '15

02 Feb '15

Hi, I'm calling for a dev meeting next thursday. We'll be back to the two-part meeting, so everyone can attend. The agenda will be here, but it is now just a copy of the last meeting's: http://wiki.koha-community.org/wiki/Development_IRC_meeting_5_February_2015 Thanks! Tomas

1 0

Search speed
by Paul A 02 Feb '15

02 Feb '15

I have progressed a little further on this subject using multiple parallel tests for from 0 to ~25k biblios on a new, relatively fast server. In brief: 3.08 averages 0.88 secs per search 3.18 averages 5.06 secs for the same searches, but... 3.18 averages only 1.52 secs if I turn off facets. Facets appear to have a huge overhead in various components of Zebra, to the point where a single core of a multiple processor CPU gets overwhelmed, but does not share the load with other totally idle cores. Intel tell me that this is not fixable through any hardware/BIOS config and they are not aware of a Linux "standard library" that deals with processor affinity. I've searched around a little and found mentions for c and FORTRAN (marvelous old memories for me!) but so far nothing totally specific for Perl. taskset and sched_setaffinity might be usable at system level, and I might have a look at pthread_setaffinity_np.3.gz I've posted test results, notes and three sets of NYTProf analysis at <http://navalmarinearchive.com/z_koha/> and would appreciate if anyone has any suggestions or comparative tests and outcomes. Thanks and best regards -- Paul

5 7