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
Test with 1 concurrent identity verification:
Operation | Median [ms] | 95% Line |
---|---|---|
Create customer | 22 | 40 |
Provide customer selfie | 134 | 203 |
Create liveness | 24 | 32 |
Passive liveness selfie with link | 24 | 31 |
Evaluate passive liveness | 117 | 184 |
Create document | 26 | 37 |
Create document front page | 878 | 1 079 |
Create document back page | 844 | 986 |
Inspect document | 105 | 147 |
Inspect customer | 765 | 818 |
Get customer | 69 | 91 |
Delete customer | 23 | 27 |
Identity verification scenario | 3 062 | 3 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 fo different number of concurrent identity verifications:
Operation | Median | 95% Line | Throughput [req/sec] |
---|---|---|---|
1 concurrent identity verification | 3 062 | 3 482 | 0.32 |
4 concurrent identity verifications | 9 174 | 10 049 | 0.43 |
8 concurrent identity verifications | 15 673 | 16 723 | 0.50 |
16 concurrent identity verifications | 31 205 | 37 210 | 0.49 |
Latency on c6a.2xlarge
Test with 1 concurrent identity verification:
Operation | Median | 95% Line |
---|---|---|
Create customer | 20 | 36 |
Provide customer selfie | 102 | 156 |
Create liveness | 20 | 21 |
Passive liveness selfie with link | 21 | 25 |
Evaluate passive liveness | 97 | 123 |
Create document | 20 | 21 |
Create document front page | 786 | 823 |
Create document back page | 731 | 767 |
Inspect document | 79 | 92 |
Inspect customer | 386 | 425 |
Get customer | 49 | 57 |
Delete customer | 20 | 22 |
Identity verification scenario | 2 337 | 2 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.
Operation | Median | 95% Line | Throughput [req/sec] |
---|---|---|---|
1 concurrent identity verification | 2 337 | 2 455 | 0.42 |
4 concurrent identity verifications | 3 596 | 3 965 | 1.02 |
8 concurrent identity verifications | 6 502 | 7 241 | 1.14 |
16 concurrent identity verifications | 11 546 | 14 720 | 1.22 |
Latency and Throughput on t3.xlarge
Operation | Median | 95% Line | Throughput [req/sec] |
---|---|---|---|
Create customer | 22 | 41 | |
Provide customer selfie | 166 | 209 | |
Create liveness | 27 | 55 | |
Passive liveness selfie with link | 32 | 60 | |
Evaluate passive liveness | 175 | 244 | |
Create document | 26 | 42 | |
Create document front page | 1 224 | 1 362 | |
Create document back page | 1 136 | 1 249 | |
Inspect document | 128 | 158 | |
Inspect customer | 697 | 817 | |
Get customer | 83 | 106 | |
Delete customer | 37 | 47 | |
Identity verification scenario | 3 800 | 4 208 | 0.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.
Operation | Throughput [req/sec] |
---|---|
Identity verification scenario | 74.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:
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.