Sizing Information and Hardware Recommendations

3DSpace Index is designed to search across metadata (basics, plus workspace / library data, attribute information, relationship information) and file content. To establish your company's hardware needs for the 3DSpace Index, you must gather information on the existing legacy system and the intended use of the new system.

The hardware you choose must be able to function in production for at least 2 to 3 years.

Memory Allocation

For optimal performance, all 3DSpace Index content must fit in memory (RAM):

• RAM for runtime (with Relationships and Octree): RAM_Runtime = 2.5kB * (NbBO + NbRel) + 3kB*NbRep
• RAM for Consolidation Server: RAM_ConsoBox = 2kB * NbRelCrawled where NbRelCrawled is the NbRel defined in the previous step.
• RAM fixed need: RAM_Fixed = 2GB (for JVM) + 16 GB (for indexing search and search handler)
• Number of CPU Core: 8 physical core for 1 Query per second (for 1000 users)
• Disk space: (RAM_Runtime + RAM_ConsoBox ) * 4

Example 1: 4 million objects (with 5% Rep, 40% Relationships)

• RAM_Runtime = 10GB+600M=10.6GB
• RAM_ConsoBox = 3.2GB
• RAM_Fixed = 18GB
• Total RAM = 31.8GB
• Number of CPU Core: 8
• Disk space = 55GB

Example 2: 12 million objects + fixed need

• 100GB index size
• 25GB Consolidation Server size
• Total RAM = 128GB
• Number of CPU Core: 8
• Disk space = 512GB

Metadata

The config.xml file controls the metadata indexed by the CloudView server. The total business object size depends on its attributes, the median size of these attributes, and whether they have default values or blanks.

Metadata is approximately 3 to 10k per business object, depending on the complexity of the data. Use this as a rough guideline to establish RAM sizing. For example, if you have 4.000.000 objects to index, this would produce a range of 12-40 GB of business object data, you want half of that: 6 GB (low end) -> 20 GB (high end) to fit in memory.

File Content

To control the file content indexed by the CloudView server, use the following config.xml file parameters:

• <FORMAT name="*"/>,
• <STORE name="*"/>
• <EXTENSION names="pdf,xls,zip,ppt,doc,txt"/>

Each file uses approximately 10K of disk space within the index. It is expected that only the latest reversion/version of a file type loads into the index.

The following table shows the typical compression ratios for a few file types. These ratios represent the expected size of the data in the index relative to the original file. For example, a 1024kb word doc expects to have about 204.8Kb of that data in the index (1024kb* 20% = 204.8kb).

Note: These ratios are ESTIMATES.

File Type	Size
RTF	90%
HTML/XML	90%
DOC	20%
PDF	20%
XLS	20%
TXT	100%

CPU

Use 1 slice for all production implementations. This setting allows you to use expand features.

The number of cores required is based on the estimated number of concurrent users. For example, if you have 12000 named users and a 1% utilization rate, you can assume 120 concurrent connections. From those 120 concurrent connections, you can expect a server processing rate of 2 queries per second. To get an optimal response rate, assume 2 cores/per query/per second plus an additional 2 core to support index building functionality. With this example, a minimum of 6 cores is required, so a selection of an 8-core machine is appropriate.

JVM Memory

Each JVM supporting CloudView requires 300MB of Java Heap Memory. The Converter process requires 300MB RAM+ (4*size of the largest file in the index).

Native Memory

The native memory size is calculated by adding the following values:

• 10% of total index size
• The number of fields in the index * The number of objects in the index * 8
• Search Handler Size, which is based on the number of objects in the index. For 0-2 million records, use a small Search Handler, 4 GB. For 2-6 million objects, a medium Search Handler, 8GB. 6 million + objects, use a large Search Handler, 16 GB.
• 4 GB