relativity performance metrics and recommendations - v9 · 2019-01-16 ·...

Performance Metrics and RecommendationsMay 2, 2014 - Version 9.3

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

For the most recent version of this document, visit our documentation website.

http://help.relativity.com/9.3

Relativity | Performance Metrics and Recommendations - 2

Table of Contents1 Performance baselines and recommendations 4

2 dtSearch index build and Search Terms Report 5

2.1 Data Grid and Search Terms Report results 5

2.2 dtSearch index build and STR settings 5

2.3 Performance recommendations 5

2.3.1 Agent configuration recommendations 6

3 Structured Analytics 7

3.1 Structured Analytics results 7

3.2 Structured Analytics settings 7


4 Analytics 9

4.1 Analytics index build results 9

4.2 Analytics clustering results 9

4.3 Analytics categorization results 9

5 Import 10

5.1 Native/Full Text import results 10

5.2 Import fields 10

6 Export 11

6.1 Export results 11

6.2 Export settings 11

6.3 Export fields 11

7 Productions and branding 13

7.1 Staging production results 13

7.2 Branding production results 13

7.3 Production import results 13

7.4 Production export results 13

7.5 Staging and Branding settings 14

7.6 Production import settings 14

7.7 Production export settings 14



8 Imaging 15

8.1 Imaging results 15

8.2 Imaging settings 15


9 Mass Save as PDF 16

9.1 Mass Save as PDF results 16

9.2 Mass Save as PDF settings 16


10 Processing 17

10.1 Discover + Publish performance baselines 17

10.1.1 Real World data set details 17

10.2 Discover + Publish performance baselines - Data Grid 18

10.2.1 Real world data set details - Data Grid 18

10.3 Processing profile and data source specifications 19

10.4 Inventory performance baselines 20

10.4.1 Inventory settings 20


11 Document Review 22

11.1 Independent document review testing results 22

12 Data set details 23

13 Environment details 24

14 Processing environment details 27


1 Performance baselines and recommendations

Note: As of the 9.3 full release, published performance metrics are final. Additional metrics will beadded as they become available.

This documentation provides an overview of performance metrics and pertinent recommendations forRelativity 9.3. For features capable of utilizing either SQL or Data Grid, performance testing was done onboth systems and noted accordingly.

Unless otherwise noted, the following all hold true for Relativity 9.3 Performance Metrics:

n All results are based on the EDRM Enron V2 data set. For more information about the data setdetails, see Data set details on page 23. For more information about the environment configurationfor this test, see Environment details on page 24.

Note: As of Relativity 9.3, the processor model on the performance Virtual Machines waschanged from 4 x Intel E5-4627 v2 3.3Ghz 8C Processors to 4 x Intel E5-4620 v2 3.3Ghz 8CProcessors. Note that performance in 9.3 may be affected by this processor model update.

n All tests were each performed individually on the environment, without any additional tests occur-ring simultaneously.

n Memory on all relevant machines was cleared immediately prior to running the tests in order to elim-inate any plausible effects of data caching.

n All performance results have a 5%variance.

For any questions, or to receive a copy of the data sets used in this performance test, please [email protected].

mailto:[email protected]


2 dtSearch index build and Search Terms ReportRelativity’s dtSearch engine provides advanced search functionality such as proximity, stemming, andfuzzy searches. It also supports the use of Boolean operators and custom noise word lists as well as thebasic searching features available in keyword searches.

Relativity’s Search Terms Report (STR) simplifies the process of identifying documents that contain aspecific group of keywords.

2.1 Data Grid and Search Terms Report resultsFor Performance testing purposes, each term within the STRwas a simple keyword; no advancedsearching functions were present. For example, proximity search, Boolean conditions, or wildcards.10,000 terms, each of which matched at least 1,000 documents, were chosen as the terms used for theterms used in the STR.

Test scenario Execution time (hh:m-m:ss)

Documents/hr Terms/hr

dtSearch Index Build 00:36:05 1,814,765 -dtSearch Index Build - Data Grid 01:09:40 960,861 -dtSearch Search TermsReport - 10,000terms

00:35:44 1,857,126 16,807

Data Grid Search TermsReport - 10,000terms

02:15:29 500,624 4,530

2.2 dtSearch index build and STR settingsdtSearch index build and STR settingsSearchable set All documents in workspace# of Documents 1,104,990Fields Included Extracted Text, Document Identifier, Group IdentifierSearch TermsReport Manager Agent 1 STRdtSearch SearchManager Agent 1 STRNumber of worker agents 1 dtSearch index buildFor more information about the data set details, see Data set details on page 23.

For more information about the environment configuration for this test, see Environment details onpage 24.

2.3 Performance recommendationsRefer to the information below when deciding how large to make a dtSearch sub-index.

Workspace document count Recommended sub-index sizeLess than 10million 250,000 documents10million to 25million 500,000 documentsGreater than 25million* 1,000,000 documents


*For workspaces with more then 25 million documents, we recommend the following when balancing yourenvironment:

Each subindex can only be searched using a single thread. At larger dtSearch index sizes, there is a trade-off between too few cores to search all of the subindexes (wastes user time) and more than enough coresto search all of the sub-indexes (wastes CPU time).

The number of subindexes in very large cases should ideally be equal to a small (1-2x) multiple of agentcore count, and be the highest number that doesn’t bottleneck one or more of the following:

n dtSearch index share file I/O

n Network between index share/agents/SQL

n Workspace database log file I/O

n Workspace database server CPU (rare)

Please contact [email protected] with questions on tailoring this to a specific environment.

2.3.1 Agent configuration recommendationsn Agent count - often the easiest and most intuitive way of making dtSearch indexes build faster is to

add more dtSearch index worker agents to the job. Only one agent can work on one sub-index.Adding more agents than the number of sub-indexes currently building will result in excess agentssitting idle.

n Agent temporary directory - you can now configure agent servers to use specific UNC paths fordtSearch builds, which allows administrators to segregate storage by agent server (reducing con-tention) or to use a NASwith faster write speeds (for building) without impacting the NASwhich isoptimized for reads (for searching).

o Use caution when modifying this setting. In a virtual environment with shared storage, chan-ging from the default may result in diminished performance due to additional data copy activ-ities performed through the index build. Relativity recommends that you test any changes onyour hardware before committing to any system-wide configuration changes.

o If shared storage is involved or the local storage is not sufficiently isolated and fast, then youshould use the default index share.

n Agent server configuration - for some other processes in Relativity, it is better to have manysmall agent servers, as opposed to a few large agent servers, or vice versa.

n Agent count - as with other processes in Relativity, adding more agents tends to make thingsfaster. Unlike other agents, however, the dtSearch search agent will utilize all resources on theserver it is running on. Because of this, there should only ever be one search agent running on anygiven agent server.

n Agent configuration - adding more CPU cores to an existing search server will make searchesfaster without any additional configuration.

n Subindex size - this number represents the maximum size of each subindex and the number ofsubindexes. While less intuitive, this is perhaps the most critical setting to get right when building theindex, as it impacts searching later. There are pros and cons to smaller indexes, such as the abilityto make parallel at the cost of higher I/O cost. Finding a good default is a high priority.



3 Structured AnalyticsThe Structured Analytics application provides the functionality to perform convenient actions such asemail threading, textual near duplicate, language, and repeated content identification on records within aworkspace.

Within the area of structured analytics, Relativity 9.3 utilizes a Textual Near Duplicate Identificationalgorithm. The algorithm greatly enhances performance for both large and complex data sets. Thealgorithm also allows users to scale their Analytics server by adding CPU cores and RAM in order toachieve faster performance.

3.1 Structured Analytics resultsThe following table provides a breakdown of Structured Analytics performance.

Test scenario Exportduration

Structured Analyticsoperations duration

Import resultsduration

Total dur-ation

Documents/hr

Language Iden-tification

0:11:48 0:06:26 0:07:42 0:25:56 2,556,532

Textual NearDuplicate Iden-tification

0:11:36 0:14:28 0:07:33 0:33:37 1,972,218

Repeated Con-tent Identification

0:11:00 0:06:39 0:00:10 0:17:49 3,721,201

Email Threading 0:12:00 0:13:32 0:08:24 0:33:56 1,953,813All operations 0:12:10 0:26:15 0:09:40 0:48:05 1,378,843

3.2 Structured Analytics settingsStructured Analytics settings ValueContent Analytics (CA) version 3.19Structured AnalyticsWorker Agents 8Each Structured Analytics operation consists of three distinct phases:

1. Export - relevant document metadata and text is exported from Relativity to the Analytics engine.

2. Structured Analytics operations - the Analytics engine processes all documents, and determinesthe relevant information to be sent back to Relativity.

3. Importing results - the data that the Analytics engine extracted from the documents is sent back toRelativity through the Import API. This phase also includes job finalization and cleanup.

For more information about the data set details, see Data set details on page 23.



3.3 Performance recommendationsThe latest version of Content Analyst (CA 3.19), which this test runs upon, allows for adding CPU power toyour Analytics server. Adding CPU power may result in performance improvements with larger data sets.Contact [email protected] for more detailed recommendations on scaling the analytics servereffectively.



4 AnalyticsRelativity Analytics helps you organize and assess the semantic content of large, diverse and/or unknownsets of documents using various Analytics features which are built upon Analytics indices.

Unlike traditional searching methods, Analytics is an entirely mathematical approach to indexingdocuments. An Analytics index is made up of both a training set that the index learns from and asearchable set that is searched upon.

4.1 Analytics index build resultsThe Analytics index build was performed using the default searchable and training sets. Start time wasmeasured as the time the first document was sent to the Analytics server, and end time was measured aswhen the last document became active and searchable. Indices were built to not automatically removeEnglish email signatures and footers.

Test scenario Operation time (h:mm:ss) Documents/hrAnalytics Index Build 00:52:06 1,272,541Analytics Index Build - Data Grid 1:01:02 1,086,875

4.2 Analytics clustering resultsRelativity clustering allows a user to create groups of conceptually similar documents utilizing an existingAnalytics index.

Analytics clustering was performed in a new cluster on all documents in the workspace. Start time wasmeasured as the time the mass operation was initiated, and end time was measured as the time the jobwas removed from the relevant queue in the database.

Test scenario Operation time (hh:mm:ss) Documents/hrAnalytics Clustering 00:32:31 2,049,440

4.3 Analytics categorization resultsRelativity categorization allows a user to create a set of example documents that Analytics uses as thebasis for identifying and grouping conceptually similar documents.

Each Analytics categorization was run using a new categorization set consisting of all documents withinthe set. Samples were taken by coding the first 1,000 or 5,000 documents with extracted text, sorted byArtifactID ascending, and coding them to one of the categories. Times were recorded from audits of thecategorization set.

Test scenario Examples Categories Operation time (hh:mm:ss) Documents/hrScenario 1 1,000 2 00:17:10 3,497,061Scenario 2 5,000 2 00:46:26 1,331,019Scenario 3 5,000 5 00:46:34 1,326,904For more information about the data set details, see Data set details on page 23.



5 ImportTo test the import performance of Relativity 9.3, the Relativity Desktop Client (RDC) was used to import afolder and its sub-folders from Relativity.

Note: Data grid utilizes non SQL storage for extracted text fields, while the remainder of the dataremains in SQL servers.

5.1 Native/Full Text import resultsTest scenario Import

timeRecords/hr MB/hr Avg Metadata

transfer rate(MB/sec)

Avg Filetransfer rate(MB/Sec)

Avg SQL pro-cess rate (doc-s/sec)

Native/Full Text(No Copy toRepository)

2:36:22 424,000 52,791 n/a n/a n/a

For more information about the data set details, see Data set details on page 23.


5.2 Import fieldsn 46 fields were imported:

o 12 long text fields (including Extracted Text)

o 18 fixed-length text fields

o 2 whole number fields

o 7 date fields

o 1 yes-no field

o 2 single-choice fields

o 2 decimal fields

o 1 multi-choice field

o 1 single-object field


6 ExportTo test the export Performance of Relativity 9.3, the Relativity Desktop Client (RDC) was used to export afolder and its sub-folders from Relativity.

All exports were completed in direct mode, copying files directly from the repository. Export was the onlyaction executing on the machine. Images were exported as single-page tiffs. Of the 1,104,990 documentstested, 100,000 had images. Extracted Text was exported into separate files. All metrics are calculatedusing the total number of documents. The average file size of all documents exported was 0.11 MB.

6.1 Export resultsThe following tables provide a breakdown of export performance:

Test scen-ario

Records/hr MB/hr .dat size(MB)

Avg FileTransferRate(MB/sec)

Metadatatransfer rate(MB/sec)

Export time(hh:mm:ss)

File size,natives +images(MB)

Natives + FullText

551,194 67,042 1,050 29.49 6.48 2:01:17 133.351

6.2 Export settingsExport settings# of Documents 1,104,990File Transfer Mode Direct Mode# of Images 290,148# of Documents with images 99,689Default Repository Access Direct ModeText Precedence Extracted textText File Encoding Western European

6.3 Export fieldsn Natives +metadata

o 46 fields were exported:l 11 long text fields (including Extracted Text)

l 18 fixed-length text fields

l 2 whole number fields

l 7 date fields

l 1 yes-no field


l 2 single-choice fields

l 2 decimal fields

l 1 multi-choice field

l 1 single-object field

n Images +metadatao 11 fields were exported:

l 5 fixed-length text fields

l 2 long text fields

l 3 date fields

l 1 single choice field


7 Productions and brandingRelativity can image and produce your documents when review completes. Production is a RelativityDynamic Object (RDO), and you can use different data sources instead of a mass operation to select thedocuments to produce. This means that you can set up a production set with a data source during anystage of document review so that you can click a button to stage and run the production when ready.

All times were measured using the timing information from the audits on the production set object.

7.1 Staging production resultsTest scenario # of documents # of data sources Total Stage Time (mm:ss) Docs/secs1 99,683 1 00:02:45 6042 99,683 2 00:02:42 6153 99,683 4 00:02:42 6154 99,683 8 00:03:00 554

7.2 Branding production resultsTest scenario Average fam-

ily sizeProductiontime (hh:m-m:ss)

Branding time(hh:mm:ss)

Images/hr

New Bates N/A 00:02:21 02:14:58 152,838

7.3 Production import resultsTestscenario

Import time(hh:mm:ss)

Images/hr Avg metadata transferrate (MB/sec)

Avg SQL processrate (Docs/sec)

Imagesonly

00:53:07 399,238.42 9.32 692

7.4 Production export resultsTest scenario Export time

(hh:mm:ss)Documents/hr Avg metadata

transfer rate(MB/sec)

Avg file transferrate (MB/sec)

Images only 00:24:14 246,807.978 341.978 14.97Natives only 00:09:07 656,048.995 160.47 26.58Natives & Images 00:34:36 172,860.694 348.18 16.11


7.5 Staging and Branding settingsStaging and Branding settings Value# of documents in production set 99,683Images 290,148Branding Agents 8Files to Produce ImagesOnlyAttachment Relational Field Group IdentifierProduction Numbering Page Level NumberLeft Footer Production BatesNumberRight Footer Control Number

7.6 Production import settingsProduction imports settings ValueCopy option NoCopy.opt file 32.0File Transfer Mode Direct Mode# of images 353,326

7.7 Production export settingsProduction export settings ValueCopy option CopyFile Transfer Mode Direct Mode# of exported documents 99,683For more information about the data set details, see Data set details on page 23.


7.8 Performance recommendationsBecause productions rely on saved searches, when constructing the searches used as processing datasources, follow best practices for searching in Relativity.


8 ImagingImaging uses Invariant workers to complete both basic and native imaging. Testing was performed forboth basic and native imagining. All imaging tests were submitted through an imaging set and timesrecorded from audits on the imaging set.

8.1 Imaging resultsTest scenario Images created Imaging time (hh:mm:ss) Images/hrBasic imaging – TIFF ~276,000 6:50:56 40,205.99Basic imaging – JPEG ~276,000 3:25:33 80.656.00Native imaging – 1 worker servers ~276,000 5:03:26 55,030.22Native imaging – 2 worker servers ~276,000 2:25:37 114,655.28

8.2 Imaging settingsImaging settingsDocument Pool 99,275Average images/document Basic 2.86 / Native 2.8Image Type TIFFImagine Set Basic image output Quality (DPI) 300Basic Image Size Original SettingFor more information about the data set details, see Data set details on page 23.


8.3 Performance recommendationsImaging does not currently have any performance recommendations.


9 Mass Save as PDFUse Mass Save as PDF to create PDFs from your images. You can also save images as single PDFs or aPDF portfolio with the flexibility to determine highlights, redactions, slip sheets, branding, and markupsets. This feature allows you to easily export a group of documents from Relativity directly from thedocument list or the related items pane.

9.1 Mass Save as PDF resultsTest Scenario Size of Zip

(MB)Total Time(hh:mm:ss)

TotalImages/hr

TotalMB/hr

Produced Images 2,710 01:43:21 14,563 1,579Produced Imageswith Highlights + Slip-sheets +Stamping + OCR

2,830 02:45:30 9,090 1,029

Native Files 169 00:02:16 750,000(pages)

5,070

9.2 Mass Save as PDF settingsTest scenario settings Value# of Imageswithin Documents 25,000Relativity Version 9.3.194.10Invariant Version 4.3.189.2Number ofWorkers 1For more information about the data set details, see Data set details on page 23.


9.3 Performance recommendationsThe maximum size of Mass PDF jobs can be limited by the Administrator through the Instance settingtable in the EDDS database. We recommend keeping the MaxNumPagesSaveAsPFD instance settingunder 25,000 pages.


10 ProcessingRelativity’s processing feature allows you to ingest raw data directly into your workspace without the needfor an external tool.

Note: To obtain the folders containing the EDRM and Real World test data sets, [email protected].

10.1 Discover + Publish performance baselinesAll time entries in the following table appear in the (hh:mm) format.

The following graphic depicts howmany GB per hour are both discovered and published, per data set, pertier of workstation setup.

10.1.1 Real World data set detailsThe following graphic represents the Real World Data set only; it depicts the breakdown of total timebetween discover and publish times, per tier of workstation setup for the Real World Data Set only.



10.2 Discover + Publish performance baselines - Data GridAll time entries in the following table appear in the (hh:mm) format.

The following graphic depicts howmany GB per hour are both discovered and published, per data set, pertier of workstation setup.

10.2.1 Real world data set details - Data GridThe following graphic represents the Real World Data set only; it depicts the breakdown of total timebetween discover and publish times, per tier of workstation setup for the Real World Data Set only.


10.3 Processing profile and data source specificationsThe processing profile used in the job that generated these performance baselines had the followingspecifications.

Note that the only field that was edited to something other than its default value was the Auto-publish setfield, which was set to Yes.

n Default time zone - UTC Coordinated Universal Time

n Defaults OCR languages - English

n DeNIST - Yes

n DeNIST mode - DeNIST all files

n Extract children - Yes

n When extracting children, do not extract - <blank>

n Excel header/footer extraction - Do not extract

n OCR - Enabled

n OCR accuracy - Medium (average speed)

n OCR text separator - Enabled

n Auto-publish set - Yes

n Deduplication method - None

n Default document numbering prefix - REL

n Default destination folder - <name of workspace>

n Do you want to use source folder structure - YesIn addition to the above settings, all of the available optional fields were mapped prior to running the job.

For more information on the processing profile fields, see the Relativity Processing User Guide.


The test data used to generate these performance baselines (the Real World data set) was selected forthe Source Path field on the processing data source. Note the following details of the Real World data set:

n File size - 60 GB

n File count - 100,000 assorted fileso 70%emails - 42 GB of various PSTs and loose emails

o 15%Office files - 10 GB of Excels, Word, PPTs,

o 10%PDF - 6GBPDFs

o 5%other (CAD files, Text files) - ~3GB

For information on creating a processing data source, see the Relativity Processing User Guide.

10.4 Inventory performance baselinesInventory allows you to narrow down your files before discovering them by eliminating irrelevant raw datafrom the discovery process through a variety of preliminary filters. With inventory you can exclude certainfile types, file locations, file sizes, NIST files, date ranges, and sender domains. Doing this gives you aless-cluttered data set when you begin to discover your files.

10.4.1 Inventory settingsInventory setupData Set RealWorld Data SetSource file Size 60GBSource File Count 100k Assorted FilesInventoried Documents 688,620Note the following file breakdown of the Source File Size:

n 70%emails - 42 GB of various PSTs and loose emails

n 15%Office files - 10 GB of Excels, Word, PPTs,

n 10%PDF - 6GBPDFs

n 5%other (CAD files, Text files) - ~3GB

Note: There is almost no contention on the file share during the publish phase, but there is some SQLcontention as data is inserted into the workspace database. SQL processor utilization will increaseduring the publishing phase.

The following graphic depicts howmany GB per hour are processed by howmany workers present in eachtier of workstation setup.


10.5 Performance recommendationsn Worker Threads - by default and if enough memory is available (750 MB/thread), Processing will

run two worker threads per CPU core on each worker server up to 16 worker threads per workermachine. Further improvements could be realized by scaling horizontally with multiple workermachines.

n Worker Machines - when scaling Relativity Processing Worker machines horizontally, it is equallyimportant to scale the file server if you want to continue to see linear improvements in performance.It will do no good to put 20+ worker machines online if your file server does not have the availableIOPS to support them.

n Invariant Queue - during discovery, the Invariant Queue Manager, workers, and default file sharefor the workspace are heavily utilized. CPU, network, and disk resources should be closely mon-itored, to detect and prevent any issues which may impact performance for other processes in thesystem, particularly review and imaging.

n Deleting of a processing set is a background process, and will only proceed while other activity is notongoing for the data store. This process may take days or weeks for large data sets or busy serv-ers. If the data deletion needs to proceed more quickly, we recommend creating the following indexin the relevant data store:

o CREATE INDEX [IX_Matter_StorageId] ON [dbo].[Matter] ([StorageId])

Note: This index must be dropped or disabled prior to further processing work using that datastore.

For more information about the environment configuration for this test, see Processing environmentdetails on page 27.


11 Document ReviewDocument review, processing, and imaging utilize the same workers.

Invariant now converts natives and images to a browser-friendly format, and the browser downloads andrenders the file. Once a document has been converted, Relativity stores the converted files on the cacheserver, and in the Converted Cache file table in the workspace. Viewing the document a second time skipsthe conversion workflow.

Careful consideration should be taken when scheduling large imaging or processing jobs due to theseshared resources. This section provides data on web server performance and response times for certainoperations, as well as performance baselines for processes using the same workers at the same time.

You'll encounter the following terms throughout this section:

n Conversion duration - the time that the user waits on conversion. Note that this time is reduced bypre-convert. This time does not include downloading the converted document.

n Cache hit duration - the time that the user waits on the system to respond with a cache ID, in theevent that the system did not need to convert a document. This happens when viewing a documentafter the first time, or when preconvert has finished converting the document while the user was ona prior document.

n Download duration - the time that the user waits on the relevant portion of the document to down-load. This includes the time to download persistent highlight set and markup set information.

n User wait time - the time taken by the download, render, and conversion or cache hit time. Thismeasures the total amount of time the user is waiting on Relativity.

n Cache hit rate - the percentage of the time when the user did not need to wait on conversion,because the document was already in the cache.

The following baselines resulted from tests run on the EDRM Enron V2 data set.

11.1 Independent document review testing resultsTestCaseScenario

Cache HitDuration (seconds)

Conversion Duration (Seconds)

DownloadDocumentTime (s)

Code Docu-ment,Save & Next

Load High-lights/Redactions

NativeReview -HTML5

0.029 1.277 0.188 0.96 0.038

ImageReview

.043 12.736 0.092 1.387 0.022

TextReview

N/A N/A 0.222 1.321 0.026

For more information about the data set details, see Data set details on the next page.



12 Data set detailsThe following are the details of the data set on which the performance tests were run:

Data set name File count Compressed Size (GB) Expanded Size (GB)EDRMEnron V2 1,104,949 40 118.10RealWorld 1,040,627 60 107.35


13 Environment detailsThe following table provides Relativity environment server specifications:

Note: As of Relativity 9.3, the processor model on the performance Virtual Machines was changed from4 x Intel E5-4627 v2 3.3Ghz 8C Processors to 4 x Intel E5-4620 v2 3.3Ghz 8C Processors. Notethat performance in 9.3 may be affected by this processor model update.

Server Memory(GB)

Cores Host details

SQL* 256 32 n Dell PowerEdge R720xd Rack Server

n 2 x Intel E5-2650 v2 2.6Ghz 8C Processors

n 256GB 1866Mhz RDIMM (16 x 16GB)

n 18 x 600GB 10KSASHard Drives, 4 x 1.2TB 10KSASDrives, 4 x 400GBSATAMLC Solid State Drives

n Broadcom 57800 2x10Gb BT / 2x1Gb BT NetworkAdapter

n PERCH710PRAID Controller


Server Memory(GB)

Cores Host details

Cache 4 4 n Dell Poweredge R820 Rack Server



n 16 x 600GB 10KSASHard Drives



Virtual File 4 4Web 1 8 8Search 64 8Data Grid -Data Note 1

16 8

Data Grid -Data Node 2

16 8


16 8

Agent 1 8 8Agent 2 8 8Invariant SQL 32 8Web2 8 8Data Grid -Master Node

4 2

Data Grid - Cli-ent Node 1

4 2

Data Grid - Cli-ent Node 2

4 2


16 8


16 8


16 8

Worker* 16 8 physical, 16logical

n Dell Poweredge R420 Rack Server



n 1 x 400GBSATAMLC Solid State Drives

n Onboard Dual Gigabit and Broadcom 57800 2x10Gb BTNetwork Adapter

n PERCH310 RAID ControllerPhysical File* 16 12 n Dell Poweredge R720xd Rack Server



n 26 x 1.2TB 10KSASHard Drives

n Qlogic 2562 Dual Port 8Gb Fibre Channel HBA


Server Memory(GB)

Cores Host details



* The Relativity SQL Server, worker servers, and physical file server are physical machines. All others areVM's.


14 Processing environment detailsIt's important to determine your infrastructure needs based on your desired throughput. We recommendthat you refer to the applicable tier to locate the necessary hardware components to complete yourprocessing infrastructure.

The below table specifies the environment these tests were conducted on. This environment falls into theTier 2 specifications as outlined in the system requirements page. See Processing system requirements inthe System requirements guide.

Note: As of Relativity 9.3, the processor model on the performance Virtual Machines was changed from4 x Intel E5-4627 v2 3.3Ghz 8C Processors to 4 x Intel E5-4620 v2 3.3Ghz 8C Processors. Notethat performance degradation in 9.3 may be affected by this processor model update.

Server Memory(GB)

Cores Host details

SQL * 256 32 n Dell PowerEdge R720xd

n 2 x Intel E5-2650 2.6Ghz 8Core Processor

n 16 x 16GB (256GB) 1866MHzRDIMM Memory

n Broadcom 57800 2x10Gb BT /2x1Gb BT Network Adapter

n PERCH710PRAID ControllerWeb 8 8 Split between two of the following:

n Dell PowerEdge R820

n 4 x Intel E5-4620 v2 3.3Ghz 8CProcessors

n 16 x 8GB (128GB) 1866MHzRDIMM Memory



Agent 8 8

File 4 4

Search/CA/Loading 64 8

Invariant SQL 32 8

Worker * 16 n 8 physical

n 16 logical

n Dell PowerEdge R420

n 2 x Intel E5-2420 v2 2.2Ghz 6CProcessor

n 4 x 4GB (16GB) 1600MhzRDIMM

n Onboard Dual Gigabit andBroadcom 57800 2x10Gb BTNetwork Adapter


Server Memory(GB)

Cores Host details

File Server * 4 4 n Dell PowerEdge R820xd

n 2 x Intel E5-2620 v2 2.1Ghz 6CProcessors

n 16GB 1600Mhz RDIMM (4 x4GB)

n 26 x 1.2TB 10KSASHardDrives



* The Relativity SQL Server, worker servers, and physical file server are physical machines. All others areVM's.


Proprietary RightsThis documentation (“Documentation”) and the software to which it relates (“Software”) belongs toRelativity ODA LLC and/or Relativity’s third party software vendors. Relativity grants written licenseagreements which contain restrictions. All parties accessing the Documentation or Software must: respectproprietary rights of Relativity and third parties; comply with your organization’s license agreement,including but not limited to license restrictions on use, copying, modifications, reverse engineering, andderivative products; and refrain from any misuse or misappropriation of this Documentation or Software inwhole or in part. The Software and Documentation is protected by the Copyright Act of 1976, asamended, and the Software code is protected by the Illinois Trade Secrets Act. Violations can involvesubstantial civil liabilities, exemplary damages, and criminal penalties, including fines and possibleimprisonment.©2019. Relativity ODA LLC. All rights reserved. Relativity® are registered trademarks ofRelativity ODA LLC.