Safe Operating Limits

THE INFORMATION IN THIS ARTICLE APPLIES TO:

• EFT v7.4.x and later

DISCUSSION

The following is a list of EFT object types and their maximum theoretical safe operating limits.

These limits were derived from quality assurance tests conducted on server hardware that meets our recommended system requirements, applying typical, but not necessarily representative, transaction and automation loads as seen by our customers.

In order to ascertain the practical safe operating limits for your specific environment, we recommend that you conduct ongoing analysis using tools such as Perfmon, capturing data collector sets of both EFT and system counters on a recurring (daily) basis over an extended period (months or years). This is especially important as the composition and configuration of EFT changes (rules added, more users onboarded, increased traffic, etc.). By juxtaposing EFT counters over system counters graphed over time, you can see evaluate the impact on the system (memory consumption, disk idle time reduction, CPU utilization, etc.), resulting in a more practical vs. theoretical evaluation of EFT’s safe operating limits within your environment.

With the resultant information you may decide that it is safe to exceed the theoretical safe operational limits to a significant degree, or conversely, that you need to improve the underlying hardware or scale out horizontally in order to achieve better performance even well within the theoretical limits. As a simple example, a single misconfigured Timer event rule set to PGP a large file once every second will max out CPU, and yet is well below the theoretical event rule limit.

When operating within the theoretical maximum safe operating limits, we will attempt to support, but cannot guarantee remedial action to hangs, crashes, or slow operations. Sometimes we may recommend scaling up or out. In other instances, we may recommend changes to your configuration that may achieve your same business goals in a more streamlined fashion. For example, crafting a single generic event rule for handling a file upload from multiple partners, rather than one rule per partner.

*includes triggers of all types; however, we do not recommend running more than a few score Folder Monitor style triggers (which by default rely on Windows’ notifications vs. polling) depending on anticipated throughput (number of files arriving, frequency, size, I/O speeds, network latency etc.). If you need to monitor hundreds or thousands of folders then we recommend either using Timer style triggers or switch your Folder Monitor triggers from notification mode to polling mode, as you can set a more relaxed polling schedule vs. real-time Windows notifications.

Likewise, Folder Monitors should never be used for monitoring files uploaded by protocols, as there is a specific event trigger type for that purpose: File Upload trigger. Using Folder Monitors for file uploads may result in a downstream race condition due to how Windows notifies based on chunks vs. whole file uploads.