Queue Management

Queue management involves assigning a team to monitor the work queues in RelativityOne. This is managed through the Queue Management tab in the admin area. The goal is to ensure jobs are prioritized and completed without affecting deadlines.

Note: This topic is about the instance-level tab called Queue Management. For information about Review Center queues, see Review Center.

Permissions

Required permissions for Queue management can be found on the Feature Permissions topic under Job Queues.

You can find the list of queues under the Queue Management tab in the administrative area. These queues include:

Branding queue

Monitor branding jobs running across an instance of Relativity. You can use mass operation options to change the job priority or export the job list. See Branding queue for more information.

dtSearch queue admin

Monitor dtSearch indexing jobs across an instance of Relativity. See dtSearch queue admin for more information.

Import/Export queue

Monitor in-progress and recently completed Import/Export jobs across an instance of Relativity. See Import/Export Queue for more information.

Mass Operations Jobs

Monitor in-progress and recently completed mass operation jobs across an instance of Relativity. See Mass Operation Jobs status for more information.

OCR queue

Monitor OCR jobs running across an instance of Relativity. You can change the job priority using the mass operation menu option. See OCR queue for more information.

PDF queue

Monitor PDF jobs running across an instance of Relativity. You can cancel a job using the mass operation menu options. See PDF Queue for more information.

Processing and imaging queue

Monitor active processing jobs running across an instance of Relativity. You can use mass operation options to cancel an imaging job, resume a processing job, change the job priority, or export the job list. See Processing administration for more information.

Production queue

Monitor production jobs running across an instance of Relativity. You can change retry jobs using the mass operation menu option. See Production queue for more information.

The Queue tab displays all jobs submitted within a RelativityOne instance, including those from Client Domains. This setup can create challenges because client domain admins cannot see the jobs in the queue. As a result, non-client domain jobs might be prioritized over client domain jobs if there isn't a dedicated team managing the queue. For more information, see Client domain best practices.

Queue management best practices

Having a dedicated team to manage queue priorities reduces waiting and completion times for targeted jobs. This approach ensures jobs are completed in a timely manner.

• Create a small team to manage queue tasks.
• Identify peak activity periods to assign active queue management roles.
• Use or create a ticketing system for both non-client domain and client domain job requests. Prioritize queue jobs based on:
  • Deadline
  • Customer priority level
  • Job size
• Actively manage queues during peak activity.
• Inform Relativity of larger-than-normal jobs ahead of time to ensure sufficient resources using the Large and Complex Matter form on the Relativity Community.
• Provide updates to priority jobs according to internal requirements.

Processing scaling and queue management

All active jobs are added to the processing queue, where the processing resource scheduler assigns resources based on job priority. Priority applies across all jobs in all workspaces at an instance level.

When you change a job's priority, it affects the order in which jobs are picked up next, without impacting any active work.

For example:

• Processing job A: Workspace 1, Priority 10
• Processing job B: Workspace 1, Priority 10
• Processing job C: Workspace 2, Priority 20

Resources will be split 50/50 between jobs A and B. Job C will wait until jobs A and B are completed before starting.

When multiple jobs run simultaneously with the same priority, resources are split equally among them. For example, if two jobs run simultaneously, the throughput is halved. If five jobs run simultaneously, the throughput is divided to 20% for each job.

There is no minimum throughput defined for processing. Internal SLOs and SLIs for processing job throughput are set at 25 Gb/hr, and these are regularly monitored across all instances to proactively address any issues.

Job throughput can be zero in two scenarios:

1. When the job has not yet been assigned processing compute because the priority of other jobs is higher.
2. When a job is stuck in processing due to environmental issues. Monitoring and alerting systems are in place to detect stuck jobs. These alerts automatically create an internal priority incident for engineering, who actively resolve the issue to ensure the job continues progressing.

As a service provider, you can request an increase in processing resources available in an R1 instance. In RelOne, customers do not need to manually administer and reassign agents and workers, as scaling is automatically managed in the cloud.

To ensure sufficient resources for larger-than-normal jobs, inform Relativity ahead of time using the Large and Complex Matter form on the Relativity Community. When you submit this request form, a ticket is created for the Site Reliability Engineering (SRE) team. The SRE team reviews the project's nature and determines the necessary resources (compute, storage, database) that can be augmented or adjusted to meet your needs.

There are no known limitations in network resources or CPU resources. The known system design limitations include job priority and factors such as a workspace not being able to have more than one publish job running concurrently. These constraints are documented on Processing throughput – Factors related to the processing publish job.

The number of jobs that can run in parallel depends on multiple factors, such as the size, the number of files, and the different file types in the dataset. For more information, see the Processing throughput factors page.

There are no other system-enforced limiters in processing. However, always try to follow best practices to achieve optimal processing performance.

Client domain resource management

Relativity can host up to 100 client domains per instance, but their activity levels matter more. Processing resources are distributed equally across all jobs in a workspace and all workspaces in an instance. Multiple concurrent jobs can reduce throughput for individual tasks and cause delays.

There are no specific performance limitations introduced by Client Domains. A RelativityOne instance hosting client domains has the same performance limitations as a normal non-client domains instance.

Please familiarize yourself with the page: Client domain limitations and considerations to understand feature limitations when using client domains.

Client domain best practices

Best practices for Client Domains focus on effective queue management to reduce wait and completion times for targeted jobs. Active queue management enables system administrators to prioritize jobs that need faster completion during peak activity periods. This is especially crucial when the total job count approaches 100 or more active jobs.

In RelativityOne, (R1) agent resources are equally divided among jobs of the same priority. If an admin needs certain jobs to be completed faster to meet deadlines, they must manually set the priority for these jobs.

By actively managing queues, administrators can host multiple complex projects without affecting other projects in the same instance. Jobs from client domains are most likely to be impacted, as their admins cannot control the prioritization of jobs generated by their users. Additionally, non-client domain jobs can be affected if system admins compete for top priority during peak activity times. Therefore, it's essential to manually set priorities for multiple jobs to ensure resources are allocated where needed.

Service providers

As a service provider, you cannot control or assign resources per client domain, as there is no mechanism for this. To increase capacity and resources in a RelativityOne (R1) instance, consider using large workspace forms. Please see:

• Workflow solutions for very large workspaces
• Recommendations for managing large and very large workspaces in RelativityOne