Performance measurements

The performance of Digital Identity Service has been measured for certain HW setups to assist with planning hte infrastructure.

Test Configuration

  • Digital Identity Service (DIS) version 1.13.0 with SSE and AVX optimalization

  • 800 times full identity verification processes

  • Test was performed by Apache jMeter.

  • Identity verification process

    • Upload selfie
    • Check passive liveness on sefie
    • Upload and OCR two sides of Slovakia nation ID card
    • Get customer & Inspect customer & Inspect customer document requests
    • Delete customer

Performance Results in Amazon AWS

DIS is running as a Docker container with Memcached container running on the same machine.

Latency on c6a.large

AWS C6a documentation

Test with 1 concurrent identity verification:

OperationMedian [ms]95% Line
Create customer2240
Provide customer selfie134203
Create liveness2432
Passive liveness selfie with link2431
Evaluate passive liveness117184
Create document2637
Create document front page8781 079
Create document back page844986
Inspect document105147
Inspect customer765818
Get customer6991
Delete customer2327
Identity verification scenario3 0623 482

As it can be seen in the table above complete identity verification with only one process running at the time takes around 3 seconds and less then 3.5 seconds in 95% the time.

Throughput on c6a.large

Throughput comparison for different numbers of concurrent identity verifications:

OperationMedian95% LineThroughput [req/sec]
1 concurrent identity verification3 0623 4820.32
4 concurrent identity verifications9 17410 0490.43
8 concurrent identity verifications15 67316 7230.50
16 concurrent identity verifications31 20537 2100.49

Latency on c6a.2xlarge

AWS C6a documentation

Test with 1 concurrent identity verification:

OperationMedian95% Line
Create customer2036
Provide customer selfie102156
Create liveness2021
Passive liveness selfie with link2125
Evaluate passive liveness97123
Create document2021
Create document front page786823
Create document back page731767
Inspect document7992
Inspect customer386425
Get customer4957
Delete customer2022
Identity verification scenario2 3372 455

As it can be seen in the table above complete identity verification with only one onboarding running at the time takes around 2.3 seconds and less then 2.5 seconds in 95% the time.

Throughput on c6a.2xlarge

Throughput comparison fo different number of concurrent Identity verifications.

OperationMedian95% LineThroughput [req/sec]
1 concurrent identity verification2 3372 4550.42
4 concurrent identity verifications3 5963 9651.02
8 concurrent identity verifications6 5027 2411.14
16 concurrent identity verifications11 54614 7201.22

Latency and Throughput on t3.xlarge

AWS T3 documentation

OperationMedian95% LineThroughput [req/sec]
Create customer2241
Provide customer selfie166209
Create liveness2755
Passive liveness selfie with link3260
Evaluate passive liveness175244
Create document2642
Create document front page1 2241 362
Create document back page1 1361 249
Inspect document128158
Inspect customer697817
Get customer83106
Delete customer3747
Identity verification scenario3 8004 2080.26

As it can be seen in the table above complete identity verification with only one process running at the time takes around 3.8 seconds and less then 4.3 seconds in 95% the time.

Performance Results on Bare Metal

Cluster of two Dell PowerEdge R7525

Machines equipped with two AMD EPYC 7763 and 192 GB RAM.

This cluster was installed with 2x7 DIS instances (one DIS instance for one CCD) and 2x1 instances of Memcached application on last CCD of the server.

OperationThroughput [req/sec]
Identity verification scenario74.60

Throughput with Horizontal Scaling

If the DIS service is scaled horizontally, you can usually achieve double throughtput or lower latency if your server are overloaded.

Scaling the infrastructure to the estimated number of transaction requests

Example Use Case

The distribution of the user requests generating server transaction has been measured across multiple installation in the fintech use case in European countries. This reflects behavior of certain population for certain use case and cannot be generalized for all use cases. Integrators of DIS are strongly encouraged to do their measurements for their use case.

A hypothetical daily request for 1000 transactions applying this behavior could be split into 10 minute slots across an average working day. The distribution can be seen on the next chart:

Daily distribution

It can be seen that during day hours, there would be in average less than 15 requests per 10 minutes, meaning any machine would by idling most of the time if only 1000 transactions are done daily.

The peak of the requests is around 40 per 10 minutes. These may come, off corse, in a short burst. It is up to the desired latency of transaction response, if a throughput of 0.5 or 1 req/sec would be needed to handle such burst.