Migrer vers la version 3.x du conteneur OCR Read

Si vous utilisez la version 2 d’Azure Vision dans le conteneur OCR Read OCR des outils Foundry, utilisez cet article pour découvrir comment mettre à niveau votre application pour utiliser la version 3.x du conteneur.

Modifications d'API

Le conteneur Read v3.2 utilise la version 3 de l’API Azure Vision et possède les points de terminaison suivants :

  • /vision/v3.2/read/analyzeResults/{operationId}
  • /vision/v3.2/read/analyze
  • /vision/v3.2/read/syncAnalyze

Consultez le guide de migration de l’API REST Azure Vision v3 pour obtenir des informations détaillées sur la mise à jour de vos applications afin d’utiliser la version 3 de l’API Lecture. Les opérations synchrones sont uniquement prises en charge dans les conteneurs.

Modifications de configuration

  • ReadEngineConfig:ResultExpirationPeriod n’est plus pris en charge. Le conteneur OCR Read comporte une tâche Cron intégrée qui supprime les résultats et les métadonnées associés à une requête au bout de 48 heures.
  • Cache:Redis:Configuration n’est plus pris en charge. Le cache n’étant pas utilisé dans les conteneurs v3.x, vous n’avez pas besoin de le définir.

Besoins en mémoire

Les exigences et les suggestions sont basées sur des tests d’évaluation effectués avec une seule requête par seconde, à partir d’une image de 523 Mo d’une lettre d’entreprise analysée qui contient 29 lignes et 803 caractères au total. Le tableau suivant décrit les allocations de ressources minimale et recommandée pour chaque conteneur OCR Read.

Conteneur Minimum Recommandé
Read 3.2 2022-04-30 4 cœurs, 8 Go de mémoire 8 cœurs, 16 Go de mémoire

Chaque cœur doit être cadencé à au moins 2,6 gigahertz (GHz).

Le cœur et la quantité de mémoire correspondent aux paramètres --cpus et --memory qui sont utilisés dans le cadre de la commande docker run.

Implémentations de stockage

Remarque

MongoDB n’est plus pris en charge dans les versions 3.x du conteneur. En effet, les conteneurs prennent plutôt en charge le stockage Azure et les systèmes de fichiers hors connexion.

Implémentation Argument(s) de runtime nécessaire(s)
Niveau de fichier (par défaut) Aucun argument de runtime n’est nécessaire. Le répertoire /share sera utilisé.
Objets blob Azure Storage:ObjectStore:AzureBlob:ConnectionString={AzureStorageConnectionString}

Implémentations de file d’attente

Dans un conteneur v3.x, RabbitMQ n’est pas pris en charge pour l’instant. Les implémentations prises en charge sont les suivantes :

Implémentation Argument(s) de runtime Usage prévu
En mémoire (par défaut) Aucun argument de runtime n’est nécessaire. Développement et test
Files d'attente Azure Queue:Azure:ConnectionString={AzureStorageConnectionString} Production
RabbitMQ Indisponible Production

Pour une redondance accrue, le conteneur Read v3.x utilise un minuteur de visibilité permettant de vérifier que les requêtes peuvent être traitées correctement en cas d’incident lors de l’exécution dans une configuration à plusieurs conteneurs.

Définissez le minuteur avec Queue:Azure:QueueVisibilityTimeoutInMilliseconds, qui fixe le temps pendant lequel un message devient invisible lorsque un autre travailleur est en train de le traiter. Pour éviter le traitement redondant des pages, nous vous recommandons de définir le délai d’attente sur 120 secondes. La valeur par défaut est de 30 secondes.

Valeur par défaut Valeur recommandée
30000 120 000

Étapes suivantes

  • Last updated on