Evergreen DokuWiki

Note: This document is a draft posted here to get feedback from the larger Evergreen community. The final document may differ significantly from what has been posted here.

The Massachusetts Library Network Cooperative (MassLNC) is seeking proposals for consulting services to conduct a software performance evaluation of the Evergreen Integrated Library System (ILS).

Evergreen is an open-source integrated library system developed by the Georgia Public Library Service to support 252 public libraries in the Public Information Network for Electronic Services (PINES) consortium. PINES completely transitioned to Evergreen in September 2006. Evergreen is now used by approximately 1,300 libraries around the world. It offers the following functionality for libraries:

• a metadata search engine;
• a transaction processing engine;
• a web application;
• and a fund management system.

MassLNC is a collaborative project among three Massachusetts library consortia that are using separate instances of Evergreen. Although MassLNC is the issuing entity for this RFP and will be the contracting entity and primary contact, when conducting this evaluation, the consultant(s) is expected to work directly with the open-source community supporting Evergreen. The budget for the proposed work is _ to _.

Evergreen is a highly-scalable system used by many large library consortia as well as individual libraries. The size of the libraries and consortia using Evergreen varies. Appendix A provides data from one particularly large Evergreen system, the Central/Western Massachusetts Regional Library System (C/W MARS) based in Worcester, Massachusetts. MassLNC and others in the community have identified places in the system where performance is suboptimal and questions they hope can be answered through a performance evaluation. The list is available on the Evergreen wiki at: http://evergreen-ils.org/dokuwiki/doku.php?id=dev:testing:performance_issues

The goal of the performance evaluation is to do a thorough audit of the Evergreen infrastructure to identify any bottlenecks that negatively impact performance in these areas and to work with the community to recommend solutions. It is not expected that the performance consultant will implement these solutions. Any recommended solutions will be left in the hands of the Evergreen community to implement.

A performance evaluation is required in the three following target areas. A more detailed overview of each of these areas can be found at http://evergreen-ils.org/dokuwiki/doku.php?id=eg_developer_overview.

The Evergreen Staff Client is currently a XULRunner application built on the XULRunner platform. XULRunner versions are roughly equivalent to Firefox versions for rendering purposes. The staff client is a combination of local and remote XUL pages, JavaScript, and the Online Public Catalog (OPAC). This includes use of the Dojo Toolkit, version 1.3 (released in March 2009). The OPAC is processed server-side with the Template Toolkit Perl Module.

Specific Issues/Questions Related to the Staff Client

The staff client has exhibited problems with memory leaks, a problem that has gotten worse at some sites with the release of Evergreen 2.3 in September 2012. Work has already begun to address these problems (see https://bugs.launchpad.net/evergreen/+bug/1086458). There have also been suggestions that an upgrade of the Dojo toolkit or the total elimination of Dojo from the staff client may resolve memory leaks and/or improve staff client performance.

The developer community has also identified the move of staff client interfaces away from remote XULRunner as a first step in improving staff client performance.

Evergreen is built upon the Open Scalable Request Framework, or OpenSRF. OpenSRF provides communication between various “Applications” and the clients that wish to call them. Each application provides a service, and usually the applications are referred to as services because of this.

OpenSRF currently works by passing JSON messages over XMPP. A very basic view of how a message passes through the system is as follows:

1. A request for a service is sent to the router.
2. The router chooses a listener and sends the request on.
3. The listener passes the message onto a drone.
4. The drone acts on the message and sends the response back to the original requester.

Specific Issues/Questions Related to Messaging

How does XMPP compare in performance to other modern messaging frameworks?

Evergreen uses PostegreSQL, both in database design and stored procedures. Most stored procedures are written in SQL, PL/pgSQL, or Perl. PostgreSQL databases are split into schemas, allowing for logical groupings of related information.

In addition to PostgreSQL itself, one should also be aware of the Fieldmapper IDL, which is one of the ways Evergreen is told how to interact with the database. Fieldmapper maps database fields to Evergreen objects.

The Fieldmapper IDL, or just IDL for short, is the Fieldmapper configuration file (fm_IDL.xml) which tells Evergreen about all of the important aspects of the database. It is comprised of a set of class nodes, each of which contains at minimum a list of fields. In addition, each class may contain links, permissions, and in the case of fully virtual classes a block of SQL that defines the data to be retrieved.

An important note: For the most part, clients and services can only talk to database elements that are defined within the IDL. The notable exception is stored procedures, which are not listed in the IDL.

Specific Issues/Questions Related to the Database

In general, are there database queries that can be optimized in the areas where performance has been identified as a problem?

In past versions of Evergreen, sites were able to utilize settings in search.relevance_adjustment to improve the relevancy of results retrieves through the Online Public Access Catalog (OPAC). As of Evergreen 2.0, many sites deactivated the settings in this table because searches became too slow (see https://bugs.launchpad.net/evergreen/+bug/844374). Is there a way to optimize searching so that tools like these can be re-implemented?

Prospective consultants should submit proposals that outline the process for the performance evaluation. The proposals should cover the following steps in the process.

Proposals should outline how the consultant will work with the Evergreen community to plan for the performance evaluation, including further identification and prioritization of areas that will be evaluated, as well as working with MassLNC to ensure that a proper testing environment is available.

Consultants are invited to submit proposals for one, any, or all of the target areas identified above (staff client, messaging, database). Proposals should outline the consultant’s methodology for measuring performance in the target area.

As part of the proposal, consultants should identify communication methods both in the planning phases and during the actual evaluation. Please indicate how status updates will be delivered through the course of the project. Please note that direct communication with MassLNC should be limited to contractual and coordination details. All other communication should be done directly with the Evergreen community using the following channels:

• The #Evergreen IRC channel on the freenode network - http://evergreen-ils.org/irc.php.
• The Evergreen Development Discussion List and General Mailing List - http://evergreen-ils.org/listserv.php.
• The Evergreen wiki - http://evergreen-ils.org/dokuwiki/doku.php?start

Central/Western Massachusetts Automated Resource Sharing, Inc. (C/W MARS) is an example of a large-scale consortium using Evergreen. The intent of the below data is to give prospective consultants an idea of the database size and level of activity that Evergreen needs to support with minimal impact on performance.

• Number of Library Systems: 149
• Number of Individual Library Branches: 170
• Number of Users: 1,133,825
• Number of Bibliographic Records (a record representing a specific edition of a title): 2,251,590
• Number of Copy records (individual barcoded items associated with the bibliographic records): 8,597,202

• Tuesday, March 5, 3-4 PM
  • Checkouts: 6,204
  • Checkins: 5,930
  • Hold Requests: 715
  • Total Checkouts, Checkins, and Hold Requests: 12,849
• Wednesday, March 6, 3-4 PM
  • Checkouts: 6,224
  • Checkins: 5,356
  • Hold Requests: 641
  • Total Checkouts, Checkins and Hold Requests: 12,221
• Thursday, March 7, 3-4 PM
  • Checkouts: 5,200
  • Checkins: 3,984
  • Hold Requests: 631
  • Total Checkouts, Checkins and Hold Requests: 9,815