atom feed4 messages in nz.co.katipo.lists.koha[Koha] Consortial ?s, load testing, E...
FromSent OnAttachments
BWS JohnsonJan 26, 2007 11:37 pm 
Joshua M. FerraroJan 28, 2007 8:01 am 
Marty JongepierJan 29, 2007 3:16 pm 
Chris CormackJan 29, 2007 9:08 pm 
Subject:[Koha] Consortial ?s, load testing, Evergreen
From:Joshua M. Ferraro (jm@liblime.com)
Date:Jan 28, 2007 8:01:04 am
List:nz.co.katipo.lists.koha

Hi Brooke,

Evergreen's a great project, Georgia PINES has accomplished their goal with it, and it's been a fantastic example of the strengths of the Open Source model for libraries. The bottom line however, is that Evergreen was designed for one VERY large public library consortium, possibly the largest in the US (252 libraries all together). As a result, it's a very complex system, and the deployment overhead is above the means of all but the biggest libraries ... for more gritty details see below :-)

----- BWS Johnson <mhel@illinoisalumni.org> wrote:

Sooooo, hypothetically, if one were to compare Koha to another OSS, say Evergreen

http://www.open-ils.org/

what would our advantages be?

There are some advantages to the new Koha version (which will be Koha 3.0). Keep in mind that I've got a vested interest in the success of both Koha and Evergreen (LibLime has done some work on Evergreen[1] and we're supporting Evergreen[2] along with Koha now).

Koha is a six-year old, mature project with code contributions from many developers, EG is quite new and built for one library system, so it won't have all the 'out of the box' options that Koha does and not as many eyes have looked at the code ...

Koha has been deployed in many types of libraries, public, academic, school, special, etc...so the features it has reflect the diversity of the community.

Koha 3.0 utilizes a textual database engine (Zebra) that was built with native support for Z39.50, SRW/SRU two very important library standards, and in fact, the Koha 3.0 OPAC you like so much is little more than a Z39.50 client. This opens up all kinds of interesting possibilities for new standards-based search interfaces ... stay tuned for some news on that soon ...In some respects, Evergreen is like Koha 1.0 as far as searching goes, it can't search the whole MARC record, only a subset of fields.

We've just re-designed the bibliographic searching and storage model and next on tap will be a next gen acquisitions and serials system based on our experiences with the current one...

Load balancing in Koha has been optimized for a single or small number of servers; because of the underlying framework, Evergreen won't scale well in a single server environment (Georgia runs it on about 50+ servers).

There are also some advantages to Evergreen, for instance, the fact that it's been deployed in a library system of 252 libraries, and that it has support for more granular permissions structure and greater flexibility for organizational hierarchies ... stuff that Koha will get as soon as a library sponsors it :-)

I know that over the years, folks have asked questions about running different libraries on one server (essentially a tiny consortium if the libraries involved have different loan periods and fines and patrons). I haven't seen one of these questions come across here in a little while, but the last time one did, I seem to remember that it was possible to have several different libraries using the same server with different fines and patrons and loan periods. Is this right?

What you describe is possible in both Evergreen and the new Koha we've been working on for the past year or so.

Do you all have things set up so that if say Stephen and I were to collaborate (I'm just using this as an example for ease of answer) would I be able to see the stuff that I keep on the shelves at Hinsdale *before* expanding my search to encompass Nelsonville?

This would be trivial to acomplish though it would require some minor customization to set up.

I see that on his catalogue (which is looking quite spiffy, by the by) if I select Nelsonville as the branch and then Bleak House as my search, I will not return the copy of Bleak House that is at Athens and Glouster. Is this something that is inherent to Stephen's catalogue? If it's not what I would like to see would be a suggestion returned from the search that I widen my search parameters in this case. (*Your* branch doesn't own a copy, but Koha finds this title at Athens and Glouster) Is Stephen's souped up catalogue available for use yet (cause I know that folks are gonna ask me that)? If so, that returns me to the question of should I really be writing my documentation for ye olde default if the souped up version of things is now the de facto default?

At least from my perspective, we'll have two stable versions of Koha for quite some time, there are a lot of smaller libraries that won't have the expertise or resources to upgrade to the new Koha, and we don't want to leave them with an unmaintained version. I know that LibLime, at least, is committed to maintaining version 2.2 for many years ahead. That said, we're definitely looking for documentation on the new system :-)

Do the number of branches top out? Has anyone done a stress test to see how many volumes and branches Koha can handle?

I've done stress tests on the bibliographic search and it can easily scale to tens of millions of records without a multi-server environment. There should be no load problems with hundreds of branches either, though you'd want to run with mod_perl turned on if you have high circulation. In a system of say, 50 - 100 branches or more, you'll definitely want to do customization of Koha, but that's the whole point, isn't it :-).

I also am aware that I can see the MARC records through the MARC view feature. Are there any plans in the works that would allow me to export an individual MARC record that I'm viewing as one might through III or Dynix? (I was thrilled to see that the subject headings on Bleak House are not fragmented. Tee hee! Thanks for making MARC cooperate)

There are plans to allow that, and in fact, I wrote a Record.pm module last year that could do just that with a tiny bit of glue code between the detail page and the module ... I just haven't had a chance to tie it together and none of my clients need it at the moment ... :-)

I might be pestering you guys with these sorts of questions quite a bit in the coming days, and I may even ring a few of you up. Please go easy on the small rural librarian that's had no reason to really look out of her cataloguing cacoon for a while now since she's been quite snug in the cuddly features she's found thus far in Koha. An exciting level of highly unofficial preliminary interest has caused this policy to change...

Pester away, we're very excited about the new version of Koha.

[1]
http://liblime.com/news-items/press-releases/georgia-library-pines-awards-contract-to-liblime/ [2] http://liblime.com/products/evergreen

Cheers,