Minimum Recommended Specs

For a small Venio deployment with all components on the same machine, the minimum recommended specifications are as follows:

On-Prem Server Specifications:

• CPU: 16 cores, 32 Threads
• Memory: 32 GB RAM

Venio Resource Specifications:

1. Processing Instances (Workers):

   • Number of Instances: 4
   • Throughput: 1-2 GBs per hour per instance

2. Desktop Client (Console):

   • Number of Consoles: 1
   • Allocation: 1 console per 8 core instances / 2 RDP sessions per console

3. Tiffing Instances:

   • Number of Instances: 4
   • Throughput: 10,000 pages per hour per instance

4. OCR Instances:

   • Number of Instances: 1
   • Throughput: 1-2 GBs per hour per instance
5.  SQL Server 2019
   • Number of Instances: 1
   • max degree of parallelism (MAXDOP): 8

When setting up the small Venio deployment, ensure that the server has adequate storage capacity for the data, logs, and backups. Preferably, use high-speed storage drives such as SSDs or NVMe drives to improve overall performance.

Additionally, ensure that the server has a high-speed network connection to facilitate efficient data transfers and communication between components.

In summary, for a small Venio deployment with all components on a single machine, you should configure the server with a minimum of 16 CPU cores and 32 GB of RAM, allocating resources as detailed above for optimal performance.

Distributed Configurations

If you need to process more than 8 GBs Per hour, we recommend a distributed configuration where the console, SQL server, distributed services servers, Web servers, and file servers are on separate VMs.

Here are our recommendations for such an environment:

Physical\Virtual Hardware

•  X1 Web server 4 procs and 16GB RAM and 200GB extremely fast storage drive. High-speed network connection, such as 10Gbps Ethernet or faster.
• X2 Processing servers 8 procs 16GB of RAM and OS with 200Gb extremely fast storage and separate 300 GB extremely fast storage drive for temp. High-speed network connection, such as 10Gbps Ethernet or faster.
• X1 Conversion servers 8 procs 16GB RAM and 200GB extremely fast storage DRIVE. High-speed network connection, such as 10Gbps Ethernet or faster.
• X1 SQL Server 16 procs and 32GB of ram, 200GB OS, one 200GB DATA drive, one 200GB Logs drive and one additional 500 GB DRIVE for backup. High-speed network connection, such as 10Gbps Ethernet or faster. The Data drives, Logs drives, and Backup drives should be the fastest drives you have access to. Splitting data, logs, and backups onto separate drives can improve SQL performance. This is because when placed on separate drives, there is less competition for the same disk resources and thus, less contention for disk access. This can lead to faster and more efficient read and write operations.

  • • As a general guideline, you can set the MAXDOP value to the number of available CPU cores. In your case, with 16 cores, you could set MAXDOP to 16. This provides a balance between parallelism and resource contention, ensuring that enough cores are available for parallel execution while still leaving resources for other queries and processes.

      However, it's essential to monitor your system's performance and adjust the MAXDOP setting as needed based on actual workloads and performance characteristics. You may need to fine-tune the MAXDOP value depending on your specific use case and workloads.

      To set the MAXDOP value in SQL Server, you can use the following T-SQL command:

      EXEC sp_configure 'show advanced options', 1; RECONFIGURE; EXEC sp_configure 'max degree of parallelism', [desired_value]; RECONFIGURE;

      Replace [desired_value] with the desired MAXDOP value (e.g., 8)..

    • Another related setting in SQL Server that deals with parallelism is 'cost threshold for parallelism' (CTFP). This setting controls the threshold at which SQL Server creates and runs parallel plans for queries.

      By default, the CTFP is set to 5, which is a relatively low value that was originally chosen many years ago when servers typically had only one or two processors. Today, with servers having many more cores, many database administrators recommend increasing the CTFP value to better balance the load of parallel and non-parallel queries.

      The ideal setting for CTFP can vary greatly depending on your workload, hardware, and other factors. It's often recommended to start with a value between 25 to 50 and then adjust it based on monitoring your server's performance and the characteristics of your workload.

      Like MAXDOP, the CTFP is not a "set it and forget it" setting, and adjusting it should be part of a process of iterative performance tuning.

      Again, it's important to carefully monitor your server's performance after making these adjustments, and you might want to involve a database administrator or a performance tuning specialist in this process if possible.

• X1 File server Hardware: At least 8 Processor Cores, at least 16GB of DDR4 RAM with at least 1TB of very fast storage. High-speed network connection, such as 10Gbps Ethernet or faster. Make sure you are not using "DFS UNC naming" UNC Naming is preferred.

AWS

•  The minimum required tier for this configuration would be AWS EC2 M5 Instances. The Recommended tier for this configuration is AWS EC2 C5 Instances. Depending on the amount of workload and resources needed, the appropriate instance type should be chosen.

Azure

• The Azure equivalent of the AWS EC2 M5 Instances is the Azure Dv3/Ev3 Instances and the Azure equivalent of the AWS EC2 C5 Instances is the Azure Dv2/Ev2 Instances.

VMware

VMware ESXi 6.7 or newer is recommended for hosting the virtual machines in this distributed configuration. Ensure that your ESXi host has sufficient resources to support the configuration detailed above, such as:

• Adequate CPU cores and clock speed
• Sufficient memory (RAM) capacity
• High-speed storage, preferably SSDs or NVMe drives
• High-speed network connectivity, such as 10Gbps Ethernet or faster

When deploying the VMs, you can use VMware vSphere to manage and allocate resources efficiently. Make sure to configure vSphere High Availability (HA) and Distributed Resource Scheduler DRS) to ensure optimal performance and fault tolerance in your environment.

For optimal performance, consider using VMware vSAN for storage, as it can provide high-speed, low-latency storage for your VMs while also improving overall storage efficiency. Additionally, VMware NSX can be used to manage and optimize network connectivity between the VMs in your environment.

In summary, to achieve the desired processing capacity of over 8 GBs per hour, you should implement a distributed configuration with separate VMs for each component, as detailed above. Ensure that you choose the right hardware or cloud resources to support this configuration, and use appropriate virtualization software such as VMware ESXi to manage and optimize your environment.

Please refer to the following guide for information on testing your environment's storage. It is imperative that your SQL server and network shares have high speeds. https://veniosystems.zendesk.com/hc/en-us/articles/16125676282387

The preferred IOPS (input/output operations per second) for a network share used by an application like Venio for e-discovery can vary based on several factors, including the size and complexity of the case data being managed and the number of users accessing the data simultaneously.

That being said, Venio recommends a minimum of 2,000 IOPS for the SQL Server storage used to store the Venio SQL database. In addition, it is recommended that the network share used to store case data provide at least 300 IOPS per service. So, for example, if you expect 4 Distributed Services, 1 OCR service, and 2 TIFF services to be processing the data simultaneously, the network share should provide at least 2,100 IOPS.

It is important to note that these are minimum recommendations, and higher IOPS can improve the performance and responsiveness of the application. Therefore, if possible, it is recommended to use storage with higher IOPS to ensure optimal performance for the application. For example, in an environment with hundreds of cases, multiple distributed services, and dozens of users making high frequency SQL database changes typically requires a storage device that can achieve at least 5,000 to 10,000 IOPS or more to store the SQL databases and SQL TempDBs to ensure optimal performance.