Skip to main content

# How to tune system performance

This section provides general guidelines on how to get the best performance from the system.

### Scalability​

When the load increases, the following services can be scaled in manual mode to stabilize

operation:

- image-api-deepfake-estimator estimates the presence of DeepFake manipulation in a facial image.
- image-api-quality-assessment-estimator evaluates the quality of a facial image.
- image-api-liveness-estimator detects faces and determines whether the face in the image belongs to a live person.
- image-api-age-estimator estimates a person’s age based on a facial image.
- image-api-gender-estimator estimates a person’s gender based on a facial image.
- image-api-face-detector-template-extractor builds a searchable biometric template from a face.
- image-api-face-detector-face-fitter detects faces and determines anthropometric points on the face.
- video-recorder-video-recorder saves video.

To scale the service, run the command below:

    $ kubectl scale deployment <SERVICE_NAME>-dep --replicas <COUNT>

where SERVICE_NAME is a service name (for example, gateway), and COUNT is a number of service instances.

### Scaling principles​

The input load depends on the web component settings. In all subsequent sections, the input load will be referred to as A and measured in requests per second (RPS).

#### Number of reference frames​

The more reference frames are provided, the higher the load on the image-api-quality-assessment-estimator and image-api-face-detector-face-fitter services (hereinafter referred to as primary processing services), since each frame is processed by them.

From these frames, the three with the highest quality are selected and additionally processed by the image-api-deepfake-estimator and image-api-liveness-estimator services (hereinafter referred to as secondary processing services).

Thus, with the standard setting of 10 reference frames, each session generates 10 requests to each primary processing service and 3 requests to each secondary processing service. If there are fewer than three reference frames, the load on primary and secondary processing services will be the same. For example, with 2 frames, each service in both groups will receive 2 requests.

For minimum processing latency with B reference frames, the services are scaled as follows:

- Number of replicas of each service in the primary processing group = A * B.
- Number of replicas for each service in the secondary processing group = A * min(B, 3)

Scaling examples where RPS and the number of reference frames differ:

RPS \ Number of reference frames | 1\10 | 2\10 | 1\5 | 1\1 | 2\1 | 1\2
--- | --- | --- | --- | --- | --- | ---
image-api-quality-assessment-estimator | 10 | 20 | 5 | 1 | 2 | 2
image-api-face-detector-face-fitter | 10 | 20 | 5 | 1 | 2 | 2
image-api-liveness-estimator | 3 | 6 | 3 | 1 | 2 | 2
image-api-deepfake-estimator | 3 | 6 | 3 | 1 | 2 | 2

#### Number and duration of checks with video recording per user session​

The number of video checks is configured by the motion control video recording parameters. The length of each video depends on the user and must be calculated based on real data.

The longer the total video duration, the higher the peak load on the video-recorder-video-recorder service. For example, with a load of 1 RPS and video verification sessions lasting 1 minute, there will be up to 60 active recording sessions simultaneously.

If the WebCodec setting is enabled, the load is handled by the processes of the video-recorder-video-recorder service. The number of processes is defined by the `decoder.decoding_process_count` parameter in the ./cfg/video-recorder.values.yaml file.

A single process can handle up to 20 parallel recording sessions via WebCodec without noticeable slowdown. It is recommended to scale the service horizontally rather than only increasing the number of processes in the configuration.

The scaling formula for a video duration of B seconds and a number of processes C:

- Number of service replicas video-recorder-video-recorder = A * B / C

Examples of scaling the video-recorder-video-recorder service with a fixed number of processes equal to 5:

RPS \ Total length in seconds of video checks in each session | 1\60 | 2\60 | 1\120
--- | --- | --- | ---
video-recorder-video-recorder | 1 | 2 | 2

When using the MediaRecorder setting, the video-recorder-video-recorder service processes are not involved, and scaling is not required.

Only video-recorder-video-recorder service is used to process motion detection video.

#### Factors independent of web component configuration​

Some load factors are independent of the component settings. At the end of each session—whether registration or authorization—the image is processed by the following services:

- image-api-gender-estimator
- image-api-age-estimator
- image-api-face-detector-template-extractor

For the image-api-gender-estimator and image-api-age-estimator services, scaling to half the load is allowed. The number of replicas is equal to: A / 2. The image-api-face-detector-template-extractor service scales 1 to 1. The number of replicas is equal to A.

Examples of the number of service replicas where RPS varies:

RPS | 1 | 2 | 6
--- | --- | --- | ---
image-api-gender-estimator | 1 | 1 | 3
image-api-age-estimator | 1 | 1 | 3
image-api-face-detector-template-extractor | 1 | 2 | 6

To save the scaling parameters, open the files ./cfg/platform.values.yaml, ./cfg/image-api.values.yaml, ./cfg/lrs.values.yaml, ./cfg/video-recorder.values.yaml and ./cfg/decoder.values.yaml, find the `replicas` field in the service block and specify the new replica values.

During next installations services will be automatically scaled to the specified values.