Skip to main content
Version: 1.17.1 (latest)

Configuration

Scalability​

When the load increases, the following services can be scaled in manual mode to stabilize OMNI Platform operation:

  • platform-processing-dep
  • image-api-face-detector-liveness-estimator-dep
  • image-api-age-estimator
  • image-api-gender-estimator
  • image-api-mask-estimator
  • image-api-emotion-estimator
  • image-api-face-detector-template-extractor-dep

To scale the service, run the command below:

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

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

note

When using GPU acceleration, the processing-dep service supports only one instance, which means that to scale it, you need to have N available video accelerators in the cluster. If you don't have multiple GPUs, you can increase the utilization by changing the processing.workers setting in the ./cfg/platform.values.yaml file.

To keep the load of A requests/sec for image processing, on a server with a physical number of CPU cores equal to B, you should set the value of replicas of each of the specified services according to the formula min(A, B).

To save the scaling settings open the ./cfg/platform.values.yaml and ./cfg/image-api.values.yaml files, find the replicas field in the service module, and set new values.

For the next installations of the platform and image-api, services will be automatically scaled to the specified values.

tip

When the number of image search requests increases, you'll need to increase the number of replicas of the image-api-face-detector-template-extractor-dep service. You can also increase the number of threads that are used to extract the biometric template.

When the number of requests for detection, creating profiles, and creating samples increases, you'll need to increase the number of service replicas:

  • platform-processing-dep
  • image-api-face-detector-liveness-estimator-dep
  • image-api-age-estimator
  • image-api-gender-estimator
  • image-api-mask-estimator
  • image-api-emotion-estimator

Change TTL of samples and activities​

caution

The default values for each parameter are specified. It is recommended to change parameter values only if clearly necessary.

caution

The activity_ttl parameter has been removed by default, since the cleaning functionality based on the amount of stored data has been added. But it is possible to enable the functionality described here; to do this, just add the backend.activity_ttl field: “2592000” to the ./cfg/platform.values.yaml file.

File ./cfg/platform.values.yaml:

  • backend.activity_ttl – duration of storing activities in the database. The value is specified in seconds. For example, 2592000 seconds (30 days)
  • backend.sample_ttl – sample storage time in the database. The value is specified in seconds. For example, 2592000 seconds (30 days)

Change the number of stored activities and events​

File ./cfg/platform.values.yaml:

  • backend.retention_activities_count – number of stored activities per workspace
  • backend.activity_handler_period – frequency of checking the number of activities in the database. The value is specified in seconds. For example, 604800 seconds (7 days)
tip

To find the optimal number of activities, you can use the following formula – a = V/(w*0.0025), where a is the number of activities per workspace; V is the desired amount of memory in GB that the activities will occupy; 0.0025 is average size of one activity in GB; w is the number of user workspaces.

File ./cfg/platform.values.yaml:

  • event_service.retention_events_count – number of stored events per workspace
  • event_service.event_handler_period – frequency of checking the number of events in the database. The value is specified in seconds. For example, 604800 seconds (7 days)
tip

To find the optimal number of events, you can use the following formula – e = V/(w*0.004), where e is the number of events per workspace; V is the desired amount of memory that events will occupy; 0.004 is average size of one event in GB; w is the number of user workspaces.

Change facial recognition method​

OMNI Platform uses facial recognition methods from Face SDK.

The method refers to the version of facial recognition model. The default method used in OMNI Platform is 12v1000. For faster work you can switch to the 12v100 method, but this will reduce recognition accuracy.

Change the method during platform installation​

At the stage of filling out the configuration files, open the ./cfg/platform.values.yaml file and replace the method in the generic.default_template_version field. Next, open the ./cfg/image-api.values.yaml file and replace the method in the fields face-detector-template-extractor.configs.recognizer.name, template-extractor.configs.recognizer.name and verify-matcher.configs.recognizer.name .

Change the method on deployed platform​

  1. Stop the platform:
./cli.sh platform uninstall
  1. Stop image-api services:
./cli.sh image-api uninstall
  1. Delete the platform database:
./cli.sh platform db-reset

  1. Open the ./cfg/platform.values.yaml file and replace the method in the generic.recognizer, backend.default_template_version, processing.recognizer_methods fields. Next, open the ./cfg/image-api.values.yaml file and replace the method in the fields face-detector-template-extractor.configs.recognizer.name and verify-matcher.configs.recognizer.name.

  2. Launch image-api services:

./cli.sh image-api install
  1. Launch the platform:
./cli.sh platform install
note

There is currently no option to switch the method for OMNI Platform with already created database. If you still decide to change the recognition method, you will need to recreate the database.

Score threshold settings​

The score parameter shows the degree of similarity of faces from 0 (0%) to 1 (100%). A high degree of similarity means that two biometric templates belong to the same person. The default threshold value is 0.85.

You can change the score threshold for OMNI Platform through the updateWorkspaceConfig API-request, where two threshold values are specified as arguments: activityScoreThreshold (The required score to link the activity to the profile) and notificationScoreThreshold (The required score to create notifications for the profile) (See Integrations for more details).

tip

Make sure the score values specified for OMNI Agent and OMNI Platform match. Otherwise, some of the activities generated from the transferred agent processes will not be linked to the corresponding profile, which means that notifications for such activities won't be received.

For example:

  • score specified for OMNI Agent = 0.7
  • score specified for OMNI Platform = 0.85

In this case, activities generated from Agent processes with a score value in the range [0.7, 0.85) will not be attached to the corresponding profile, and notifications for them will also not appear.

Send emails to SMTP server​

  1. Stop the deployed OMNI Platform:

    ./cli.sh platform uninstall

  2. Make changes to platform-email-secret in the ./cfg/platform.secrets.json file.

  3. Recreate secrets:

    ./cli.sh platform install-secrets

  4. Deploy OMNI Platform:

    ./cli.sh platform install