The information in this article is meant to provide general guidelines and best practices for optimizing performance through an increased understanding of the software and proper architecture planning and implementation.
Hardware Architecture and Configuration
The performance of AccessData's Processing Technology is bound by the hardware it operates on. When optimized properly, the Processing Engine (EP) can use up all available CPU, RAM, and Disk I/O it has available to it. For the very best performance, it is recommended that a system be implemented using the latest technologies in processing cores, memory, and Disk I/O. Ideally, the latest multi-threaded processors, Solid State Drives (SSD) RAID'ed for performance, and large volumes of memory would be utilized to process large and complex data sets at blazing fast speeds. As the availability of these new technologies is restricted by budget, the following guidelines were written to assist in optimizing an efficient solution.
As stated in our spec guides, AccessData strongly encourages the use of physical hardware platforms in any implementation of our solutions. The support of any implementation which attempts to host one or more components on virtualized platforms is subject to the discretion of AccessData. AccessData reserves the right, during the troubleshooting of a support issue, to withdraw support on a specific issue if it is found to be induced by virtualization.
NOTE: VIRTUALIZATION USING MICROSOFT HYPER-V IS NOT SUPPORTED.
AccessData forbids the installation of any AccessData components on any system that hosts a Microsoft Domain Controller.
For best performance, the following data and/or directories should have enough I/O to minimize or eliminate disk queue during processing. Typically, this means putting them on their own, separate disk I/O bound hardware RAID arrays and using solid state storage rather than spinning disks. RAID controllers with at least 512MB of write-through cache provide the greatest performance increase. Software RAID is not supported.
- Database Files (i.e., separate disks for DB Files, DB Logs, and TempDB)
- Evidence Files
- Job Folder (PM directory)
- Case Data Files
The Job Folder or Processing State Folder (PM directory) does not necessarily need its own disk separate from other components and has proven to function well when placed on the same volume as the ADTemp. However, it does require fast I/O (SSD recommended, 10k RPM HDD minimum).
It is recommended that, in a multiple-server environment, high throughput networking connections (10Gbe) be used for networking the servers together. Neither iSCSI nor NIC teaming are recommended and have been proven to yield inferior performance to fiber connections when interfacing with a SAN. Link Aggregated Control Protocol (LACP) is not supported.
CPU and Memory
The server hosting the Evidence Processing Engine (EP) should meet or exceed a ratio of 2:1 memory to logical CPU cores (processing threads). Recommendations for all other component servers can be found in the system spec guides.
For all components (and especially the Processing Engine) the quality of the processors employed in the environment will have a direct effect on the overall performance of the software. Sites such as cpubenchmark.net can be used to compare the relative performance of different processors. Additionally, some components use the number of logical processor cores on a system to calculate the total number of threads available to perform certain operations.
Where possible, AccessData recommends using a dedicated server for processing. This typically means installing only the Distributed Processing Engine (DPE) on a server without any other application components. The DPE (while processing) will use all available resources as much as it is able. This means it will attempt to take resources from the other services and components, or surrender them, negatively impacting performance.
It is also recommended that the database platform be installed on a system dedicated to this component and configured with separate physical drive sets (i.e., RAID arrays) to store the most I/O intensive data types (db data files, db logs, and temp db). Please see the product Specification Guides and Disk I/O section above for more detail.
The following are recommend changes to be made in the system BIOS where available:
- Change memory utilization settings to enable “Node Interleaving.” This disables NUMA and allows for even access to shared memory resources.
- Set CPU performance to the “Performance” setting. Some systems have a default performance setting of “Performance-per-watt” for a power saving mode.
General Windows Optimization
Anti-Virus and Indexing
It is recommended that any anti-virus software and Windows Indexing Service be set to exclude the same directories listed in the architecture section above. If either AV scanners or Windows Indexing Service is attempting to scan the data in these directories while the system is accessing this data, it can significantly degrade the performance of the overall system and cause failures in some situations.
During processing, AccessData's Processing Engine (EP) creates a large amount of temporary files generating I/O and dividing, processing, indexing, and distributing work. This can cause severe disk fragmentation on drives containing specific data directories. Fragmented hard drives will lead to a decrease in performance and increase in processing times. AccessData recommends that SSD's (ideally RAID'ed SSD's) be used for the following directories:
- Job Folder (PM directory)
- Processing Database Data Files
- Processing Database Temporary Files
If hard disk drives (HDD) are used, a maintenance plan should be created that involves a periodic de-fragmentation job be run. Be aware that running de-fragmentation and processing data simultaneously runs the risk of introducing processing errors. The maintenance plan should include a coordinated schedule that avoids de-fragmentation of HDD’s during processing.
AccessData endorses the recommendations made by Microsoft in relation to page file settings (http://support.microsoft.com/kb/2860880). In Windows, when an application creates an entry in the file cache, it also must create an entry in the system cache. As a best practice, all servers should have a page file set at 1.5-2 times the available RAM in fixed size (not Windows managed) and stored on a drive separate from the OS. A separate RAID 0 volume or SSD for the page file is ideal.
Change Windows Power Options to “High Performance.” For Server 2008 R2, the default setting is “Balanced” which will throttle CPU during low usage times. This causes delays during the “ramp up” phase of processing data and can cause processing “hangs.” Sleep or Hibernation should also be disabled to prevent the system(s) from powering down during use.
Windows Updates should not be set to automatically install. This can force reboots during processing and/or review. Planned maintenance periods should be scheduled to install updates and reboot the system(s) to avoid problems during product use.
User Account Control (UAC) should be disabled on all servers during installation and ongoing use to avoid access and performance issues.
If it is not being used, IPv6 should be disabled using this Microsoft KB article. This will prevent the system from attempting to use it.
8dot3name (Microsoft KB Article) ("fsutil behavior set disable8dot3 1").
Database maintenance is required to prevent poor performance and can provide recovery options in case of failures.
Microsoft SQL Server (MSSQL)
The article linked here contains the information on recommend MSSQL database maintenance.
This article contains database maintenance information for Postgres.