Performance measurements
The performance of Digital Identity Service has been measured on AWS platform to assist with infrastructure planning, focusing on the exhaustive identity verification scenario. All testing images were generated by DOT Mobile and Web components.
Evaluation
Identity verification process:
- Upload selfie
- Check passive liveness on selfie
- Upload and OCR two sides of Slovakia national ID card
- Get customer & Inspect customer & Inspect customer document requests
- Get document front & back page
- Delete customer
Total of 750 full identity verification processes were evaluated. With 3 concurrent threads, the throughput reached 0.41 verifications per second.
| Operation | Median [ms] | Average [ms] | 95% Line |
|---|---|---|---|
| Create customer | 20.00 | 23.20 | 37.00 |
| Provide customer selfie | 213.00 | 226.92 | 382.90 |
| Create liveness | 13.00 | 15.76 | 28.00 |
| Passive liveness selfie with link | 32.50 | 35.50 | 51.95 |
| Evaluate passive liveness | 642.50 | 689.73 | 965.60 |
| Create document | 14.00 | 15.85 | 29.00 |
| Create document front page | 2110.50 | 2138.44 | 2830.15 |
| Create document back page | 2195.00 | 2214.52 | 2861.60 |
| Inspect document | 616.50 | 669.75 | 1005.00 |
| Inspect customer | 899.00 | 933.30 | 1287.85 |
| Get customer | 51.00 | 55.86 | 102.85 |
| Get document front page | 87.00 | 97.39 | 163.95 |
| Get document back page | 88.00 | 99.80 | 172.85 |
| Delete customer | 17.00 | 20.15 | 32.95 |
| Identity verification scenario | 7146.00 | 7236.17 | 8516.90 |
Upon evaluation, the CPU utilization of DIS peaked at approximately 85%, with consistent memory usage.
NOTE: Please note that the aforementioned performance was measured on a minimal requirements configuration and your results may be improved by using a machine with more CPU cores or horizontally scaling the application to achieve your desired results.
Configuration
Digital Identity Service
- Version: 1.50.0
- Deployment: DIS is running as a Docker container deployed on an AWS machine with resources equivalent to an AWS c6a.xlarge instance.
The server is using the default application configuration with SSE and AVX optimization enabled.
The Docker image is built using Dockerfile provided in the distribution package.
Redis
- Version: 7.1.0
- Deployment: AWS Elasticache cluster with one cache.m6g.large node.
Testing Tool - Jmeter
- Version: 5.5
- Deployment: Jmeter is running as a Docker container deployed on an AWS machine with resources equivalent to an AWS c6a.xlarge instance.
Testing Setup
The setup involved deploying a single instance of DIS, which was connected to a Redis cluster running on a separate machine. The testing client was deployed as a single instance generating requests across multiple threads. All services were deployed within the same region on the Amazon AWS platform to mitigate network latency.
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 course, 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.