<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Exchange Server">
<!-- converted from rtf -->
<style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left: #800000 2px solid; } --></style>
</head>
<body>
<font face="Gill Sans MT, sans-serif" size="2">
<div>According to my geek we have rebuild_zebra.pl running on a cron. Monday we updated the server's OS and migrated to a newer version of Koha (from 3.01.00.001 to 3.01.00.145). I went through the Administration and System Preferences, most of which migrated
over with the old settings. It seems that it was my fault that certain transactions (search, circulation) were taking a long time!</div>
<div> </div>
<div>Under Zebra, our old Koha states "if ON, Zebra indexing is turned off, simpler setup, but slower searches. Warning: using NoZebra on even modest sized collections is very slow" which meant very little to me ;-) and we were not using Zebra. The new Koha
has "Use/Don't Use the Zebra search engine. Searches are very slow on even modest sized collections when Zebra is off" which makes a lot more sense to me ;-) and we are now using Zebra.</div>
<div> </div>
<div>Additionally, CataloguingLog was set to log changes. The new Koha says "since this occurs whenever a book is checked in or out as well, it is not advisable to turn this on" and has been set to not log.</div>
<div> </div>
<div>Our most problematic items now take seconds (~3) instead of minutes (~2.5) to check in or out!</div>
<div> </div>
<div>I experimented with turning off IssueLog and ReturnLog but noticed no difference in transaction time.</div>
<div> </div>
<div>Rachel Hollis, librarian</div>
<div>Stevens-Henager College, Boise Idaho Campus</div>
<div> </div>
<div>2010 Winner of Best Places to Work in Idaho</div>
<div> </div>
<div>-----Original Message-----<br>
From: Chris Cormack [<a href="mailto:chrisc@catalyst.net.nz">mailto:chrisc@catalyst.net.nz</a>]
<br>
Sent: Thursday, August 19, 2010 4:24 PM<br>
To: Rachel Hollis<br>
Cc: Koha@lists.katipo.co.nz<br>
Subject: Re: [Koha] slow response time</div>
<div> </div>
<div>* Rachel Hollis (Rachel.Hollis@stevenshenager.edu) wrote:</div>
<div>> Greetings friends, our Koha 3 has about 5600 items and 1400 biblios; some biblios have 100s of items. We are experiencing very slow response times with transactions involving biblios with many items. We have many circulations for a day or two once a
month and some titles take several minutes to check-in or out, while our patrons wait in line.</div>
<div>> </div>
<div>> According to my geek, Zebra (version 2.0.32) appears to rebuild the item index for either the entire database or the biblio (my area of fuzziness) after each transaction. Is this the way Zebra is supposed to operate? If so, is there a way to rebuild
indexes overnight? If there is another solution, we'd love to hear it.</div>
<div>> </div>
<div>Are you running the zebraqueue_daemon ? If so, don't. Run the the rebuild_zebra.pl script using cron at a suitable interval. Having said that, Koha doesn't spawn the reindex at circ, it puts in a queue that another process then uses. </div>
<div> </div>
<div>So I doubt it is zebra that is the problem in this case, unless zebra is reindexing so much that it is cases too much I/O and stopping mysql being able to work.</div>
<div> </div>
<div>Much more likely is the fact that the marc record is updated at circulation, and that is slower with larger marc records (ones with 100's of items attached) than with smaller records.</div>
<div> </div>
<div>We plan to shift the item level data back out of the main record, so that no longer happens, but only the individual item is changed (not the entire record). And instead combine them for index/export. This will be in the 3.4.0 release. </div>
<div> </div>
<div>So in summary, don't run zebraqueue_daemon, run rebuild_zebra.pl as a cronjob at some interval you decide on, but I dont think zebra is the issue.</div>
<div> </div>
<div>> We are running Koha 3.01.00.001 on Debian Etch with Zebra on a P4 beater box running right next to my desk, available only on the intranet. We use Google Chrome as our interface to Koha.</div>
<div>></div>
<div>Thats a really really old version of 3.1.x, upgrading won't change this issue, but it will certainly fix hundreds of other bugs.</div>
<div> </div>
<div>I guess you are waiting for the release candidate (3.1.x is the development number for 3.2.x)</div>
<div> </div>
<div>Chris</div>
<div> </div>
<div>> Rachel Hollis, librarian</div>
<div>> Stevens-Henager College, Boise Idaho Campus</div>
<div>> </div>
<div>> 2010 Winner of Best Places to Work in Idaho</div>
<div>> </div>
<div>> </div>
<div>> This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the email by
you is prohibited.</div>
<div>> _______________________________________________</div>
<div>> Koha mailing list</div>
<div>> Koha@lists.katipo.co.nz</div>
<div>> <a href="http://lists.katipo.co.nz/mailman/listinfo/Koha">http://lists.katipo.co.nz/mailman/listinfo/Koha</a></div>
<div> </div>
<div>--</div>
<div>Chris Cormack</div>
<div>Catalyst IT Ltd.</div>
<div>+64 4 803 2238</div>
<div>PO Box 11-053, Manners St, Wellington 6142, New Zealand</div>
<div> </div>
<div><font face="Times New Roman, serif" size="3"><br>
</font></div>
<div><font face="Times New Roman, serif" size="3"><u> ________________________________ </u></font></div>
<div><font face="Verdana, sans-serif" size="1" color="#808080">This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately
and delete the original. Any other use of the email by you is prohibited.<br>
</font></div>
</font>
</body>
</html>