[Koha] Consortial ?s, load testing, Evergreen
Joshua M. Ferraro
jmf at liblime.com
Sun Jan 28 08:00:52 NZDT 2007
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 <mhelman at illinoisalumni.org> wrote:
> Sooooo, hypothetically, if one were to compare Koha to another OSS,
> say Evergreen
> 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 and we're supporting Evergreen 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
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+
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
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
> 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
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.
Joshua Ferraro SUPPORT FOR OPEN-SOURCE SOFTWARE
President, Technology migration, training, maintenance, support
LibLime Featuring Koha Open-Source ILS
jmf at liblime.com |Full Demos at http://liblime.com/koha |1(888)KohaILS
More information about the Koha