• EFT v7.4.x and later

DISCUSSION

The following is a list of EFT object types and their maximum safe operating limits. These limits were derived from numerous quality assurance tests conducted on server hardware that meets our recommended system requirements. (Refer to the help documentation for your version of EFT.)

As mentioned above, this article discusses LIMITS of the software as determined by QA tests. Various external limitations are outside of the control of EFT and can affect performance within your environment. Refer to Globalscape Recommendations for High Performance for details of the limitations (such as network, disk I/O, memory, CPU, antivirus, Windows updates) and how to overcome them.

Upon service startup, EFT v8.0.5.7 and later will do a count of these objects and write a warning to the Windows Event Log and WARN log to eft.log if a limit is exceeded.

It may be possible to exceed these safe operational limits to a significant degree if the underlying hardware is improved; however, as objects increase, and depending on their composition and configuration, risk of adverse performance will also increase.

Globalscape will attempt to support, but cannot guarantee remedial action to hangs, crashes, or slow operations that are or appear to be a by-product of exceeding maximum safe operating limits as defined here. In v8.0.5 and later, a limits.json file is available in the \ProgramData\Globalscape\EFT Server Enterprise folder.

If you find yourself exceeding these limits, we recommend reaching out to us. Sometimes we can recommend configurations that 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.

The performance of the computer/virtual machine on which EFT is running is the key to reaching upper limits. Reaching max EFT limits requires a powerful computer, such as 16 logical processors, SSD disks, and so on.

The count of the objects is the entries shown in the SiteConfig.db, not what is shown in the administration interface. That is, if the entry exists in the DB file it will be counted towards the limit. The underlying database is more detailed than the administration interface, such as including all paths for a given virtual folder.

We recommend Monitor-style triggers when a file is created on the filesystem (which by default rely on Windows’ notifications vs. polling) without traversing protocol traffic (HTTP/S,SFTP,FTP/S etc.) depending on anticipated throughput (number of files arriving, frequency, size, I/O speeds, network latency etc.). 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.

For additional control on File Upload triggers used by protocol traffic, please read this Flow: Subroutine Action (helpsystems.com). Or contact our Services  team to help you design your event rules