This file holds all the settings that might vary between servers, while all the settings that are relevant for the entire installation are defined in the databaseג€™s general parameters table (see below).

Changes in the global_properties file take effect only after running the script $dps_dev/system.dir/bin/set_globals.sh.

In a two-tier topology, before changing the the APP_ROLE of a certain server, the System Administrator must update [module].server in global.properties with the correct FQDN for each module (before running the set_globals script). If a load balancer is applied, update load.balancer.[module].host and load.balancer.[module].port for each relevant module.

Cases that require the Administrator to run the rosettings.csh script include:

In any of these cases, we strongly recommend that you consult first with the Rosetta Support team.

To increase the computing power of Rosetta, you can use more than one server with the same application role. In this case, all the servers that work with the same application role should have a load balancer that balances the load between them.

When adding or modifying the load balancer settings, the URL must be changed in the global.properties file of each server. To apply the changes, the System Administrator must run the $dps_dev/system.dir/bin/rosettings.csh script.

Rosetta uses worker threads to handle back-end processing. Such back-end processes include:

SIP processing resources can be configured on each server in order to optimize the performance of the system. These settings are configured out-of-the-box for a server of typical computing power in line with the Rosetta system requirements. Installations with larger or smaller servers may need to adjust these settings to achieve an optimum utilization of system resources. In addition, worker threads can be configured to create a server that handles only specific functionality within an application role. A typical use case could be the need to allocate enough computing power for front-end activity (such as Web deposit and Delivery) while back-end activities such as maintenance tasks run in the background.

To adjust these settings, log on to the Rosetta Administration site and follow the path from the Administration page: System Configuration > General > SIP Processing Workers.

The Level parameter is a 0-10 value that determines the SIP processing load for the entire environment by setting all servers to default and adjusting the default value, or by individually adjusting each SIP processing server (DEP, REP, and PER).

To ensure UI high-availability, lower the level on one or more of your REP servers, or consider reserving one of your REP servers for UI functionality by setting its level to 0.

An indication of a balanced and fully-utilized SIP processing configuration is one in which the number of waiting SIPs is constantly approaching 0 and the number of SIPs in process is steady (the actual number naturally depends on the number of servers). Adjust the Default Level to apply changes to all servers set to Default, or adjust servers' levels individually. If the number of waiting SIPs is rising and SIP processing level is at maximum (and/or cannot be increased in order to reserve UI resources), you may require additional hardware resources to achieve better throughput. Please consult the Rosetta Support Team and Ex Libris Sizing Manager for further analysis.

Users with heavy SIP loading needs may also want to reserve Operational server resources for end-user-facing modules by detaching the Operational servers that handle SIP processing from the load balancer. The load balancer would direct all requests to servers with a low level of SIP processing workers (or none at all), ensuring high availability.

Libraries that are interested in setting up such a topology should contact Rosetta Support.

To have several worker processes allocated per SIP, select the Run in Parallel check box. This allows Rosetta to process a large amount of files much more quickly.

SIP processing can be configured to refrain from processing additional SIPs when the system load average (during the last minute) is above a certain level. The load average is calculated similar to the top UNIX utility, taking into consideration memory usage and CPU utilization. This setting is useful when unusually large SIPs are deposited sporadically and unpredictably, in order to prevent Rosetta from unexpectedly running out of resources.