Review Center performance baselines
This page acts as a reference to track the general performance of Review Center in RelativityOne.
Because of data and configuration differences, do not use this as a benchmark for what to expect in your own organization's environment. The results may not scale linearly.
Queue size recommendations
For the best user experience, we recommend limiting the queue size as follows. These numbers are based on extensive testing in RelativityOne.
| Volume Type | Limit | Notes |
|---|---|---|
| Max documents in saved search | 5,027,765 documents |
We recommend a maximum of roughly 5 million total documents in the queue's data source. |
| Max coded documents | 1,000,000 documents | We recommend a maximum of roughly 1 million total coded documents in the queue's data source. |
Performance testing definitions
For these tests, the times listed include the time taken to populate the queue, build the model, and load the results into the Review Center dashboard.
The start and end times are measured as:
-
Start time—the time the user clicked the button to start the job.
-
End time—the time the last document became available in Review Center.
Overall build speed
In a queue with 1 million documents, 10 of which were pre-coded, an initial build took slightly over an hour. It populated data into the queue at a rate of 13.57 gigabytes of data per hour, or 920,000 documents per hour.
The tabulated data is as follows.
| Documents in queue | Pre-coded documents | Total run time (h:mm:ss) | GB per hour | Documents per hour |
|---|---|---|---|---|
| 1,000,000 |
10 |
1:05:50 | 13.57 | 920,000 |
Build time variance with document coding and caching
The following tests used a queue that contained 1 million documents, but each test had a different number of pre-coded documents. These documents were randomly coded 50% responsive and 50% non-responsive.
Each test also recorded the time it took to complete a second build. After the initial run, later builds use cached document tokens, which substantially speeds up the process.
| Test Number | Pre-coded documents | Time for initial run (h:mm:ss) | Time for subsequent run (h:mm:ss) |
|---|---|---|---|
| Test 1 | 10 | 1:05:50 | 0:17:18 |
| Test 2 | 100,000 | 1:08:50 | 0:20:15 |
| Test 3 | 200,000 | 1:06:05 | 0:19:28 |
| Test 4 | 300,000 | 1:02:19 | 0:21:19 |
| Test 5 | 400,000 | 0:59:42 | 0:21:58 |
| Test 6 | 500,000 | 1:01:23 | 0:17:42 |
| Test 7 | 600,000 | 0:58:06 | 0:23:51 |
| Test 8 | 700,000 | 0:52:38 | 0:16:17 |
| Test 9 | 800,000 | 0:56:36 | 0:17:05 |
| Test 10 | 900,000 | 1:07:43 | 0:20:07 |
| Test 11 | 1,000,000 | 0:58:43 | 0:21:07 |
Build time variance with more documents
The following tests used a queue that contained 5,027,765 documents. Like previous tests, each test had a different number of pre-coded documents. These documents were randomly coded 50% responsive and 50% non-responsive.
Each test also recorded the time it took to complete a second build. After the initial run, later builds use cached document tokens, which substantially speeds up the process.
| Test Number | Pre-coded documents | Time for initial run (h:mm:ss) | Time for subsequent run (h:mm:ss) |
|---|---|---|---|
| Test 1 | 10 | 4:14:49 | 0:48:11 |
| Test 2 | 300,000 | 4:27:43 | 0:49:11 |
| Test 3 | 400,000 | 4:35:43 | 0:50:02 |
| Test 4 | 700,000 | 4:53:09 | 0:47:46 |
| Test 5 | 800,000 | 4:02:12 | 0:58:08 |
| Test 6 | 900,000 | 4:34:30 | 0:52:27 |
| Test 7 | 1,000,000 | 4:04:45 | 0:54:06 |
