Optimal Performance Recommendations

MegaMatcher Accelerator is intended for large-scale biometric systems with data from millions of people, expected intensive usage and managed maintenance. Optimal MegaMatcher Accelerator performance and availability can be achieved in the following conditions:

• Large enough database size to make use of Accelerator's fast matching engines
• Enough simultaneous requests to make use of Accelerator's matching capabilities
• Relatively small number of new enrollments during identification process to keep matching speed high enough

Large enough database size

At least 1,500,000 fingerprints or irises in a database for a single MegaMatcher Accelerator 3.0 Extended unit or at least 700,000 fingerprints or irises for a single MegaMatcher Accelerator 3.0 Standard are recommended to achieve the optimal matching speed. Systems with smaller databases will show less efficient average performance, as every identification request requires some time for communications and other internal operations that does not depend on the database size.

For smaller biometric systems integrators may consider MegaMatcher Cluster or MegaMatcher Server instead of MegaMatcher Accelerator.

Enough simultaneous requests

Identification requests number should be enough to process 24 identification tasks in parallel when MegaMatcher Accelerator 3.0 Extended used or process 8 identification tasks in parallel when Accelerator Standard used. Smaller amounts of parallel requests will not utilize all MegaMatcher capabilities as it is designed to provide the declared performance when multiple identification requests are sent simultaneously.

Relatively small number of new enrollments during identification

No new enrollments during identification process or the number of new enrolled templates should be relatively small compared to the the actual database size already stored in an Accelerator. The new enrolled templates in a MegaMatcher Accelerator are matched at a lower speed until conversion to the Accelerator internal data structures (flush) will be applied. Already flushed templates part will be matched at fast speed but the Accelerator matching performance will decrease due to still non-flushed templates influence:

The time required for flush does not depend on the number of newly enrolled templates, but depends on the size of the whole database stored in a particular MegaMatcher Accelerator:

The template flush should be done periodically to keep high Accelerator performance. The flushing process takes some time and MegaMatcher Accelerator is unable to process matching tasks during flush.

If high availability required, several options can be used to ensure effective system work:

• Optimal flush frequency can be selected depending from enrollment rate, database size and other factors to minimize flush time and average matching speed loss.
• Scheduled flush (i.e. during night) if high availability is needed only during certain hours.
• An additional MegaMatcher Cluster, Accelerator or cluster of Accelerators working in parallel will allow to process matching requests if the main Accelerator is not available due to flush.
• New enrollments sent to a separate MegaMatcher Cluster or MegaMatcher Server running in parallel with the main MegaMatcher Accelerator. The Cluster or Server will store the new templates and process matching requests in parallel with the MegaMatcher Accelerator until the next scheduled Accelerator flush when they can be send to the Accelerator and stored there.

Go to MegaMatcher Accelerator contents