Tuning CollectionSpace for Performance
This document discusses some of the configuration changes ("tuning") you can make to a CollectionSpace system that have the potential to enhance its performance.
Changes of this type are generally appropriate to be made by an experienced system administrator or implementer, or by a software developer. Often, these changes involve selectively changing a single configuration option or closely related set of options, then carefully measuring changes in performance for selected operations, to determine whether they have had the desired impact and have not introduced unacceptable tradeoffs.
Changes that can improve performance in the server
The following changes, also made via build or configuration changes on the server, have the potential to significantly improve the responsiveness of CollectionSpace's Services layer: the speed at which that layer can return data in response to requests.
Configuring the database to support your large dataset
If your CollectionSpace system contains many tens of thousands, or even hundreds of thousands or millions of records - especially when considering all record types in your system, including relationships between records, which are themselves stored as records - you may find it advantageous to "tune" your database to support your large dataset.
These documents include a section on tuning PostgreSQL:
Designating fields as "prefetched"
Fields whose values are routinely returned in lists and in search results should be designed as "prefetched," to enhance retrieval speed. These are the fields whose values appear in places such as:
- Search results on the Find and Edit page
- The right sidebar on Cataloging and procedural record pages
- Search results within the dialog for relating records
In general, a CollectionSpace system comes with most or all of these fields already designated as "prefetched." In case you might need to selectively configure these settings, this document describes how to do so:
How to designate fields as "prefetched"
Currently, due to a technical limitation, multivalued fields and fields in multivalued groups (e.g. the Title field in Cataloging records) can't be designated as prefetched. This may no longer be true as of CollectionSpace version 2.0.
Designating selected fields as indexed
Fields on which CollectionSpace will frequently be performing database lookups - retrieving specific records by their values - may be candidates for indexing. In some selected cases, adding indexes will improve the performance of those database lookups, and thus overall system performance. (There are also tradeoffs when adding indexes, relating to memory use and availability, speed of creating and updating records, and so on; and in some instances, lookups using indexes can actually perform more slowly than sequential lookups.)
In general, a CollectionSpace system comes with a minimal, yet sensible, set of fields already designated as indexed. Beyond this, a software developer, database administrator, or an experienced implementer will typically need to look at the types of queries performed against the database, and the performance of those queries, both with and without indexes, to identify which additional fields might benefit by being indexed, if any. (As well, there are also database-specific configuration settings that you may need to tune, to ensure that the database uses those indexes appropriately when performing queries.)
CollectionSpace provides two mechanisms, independent of any configuration settings for any database type or instance, you can use to ensure that your designated fields are indexed: