Performances et mise à l’échelle pour Event Hubs et Azure Functions

Cet article vous aide à optimiser les performances et l’évolutivité lorsque vous utilisez Azure Event Hubs et Azure Functions dans vos applications.

Regroupement des fonctions

En règle générale, une fonction encapsule une unité de travail dans un flux de traitement d’événements. Par exemple, une fonction peut transformer un événement en une nouvelle structure de données ou enrichir des données pour des applications en aval.

Dans Azure Functions, une application de fonction fournit le contexte d’exécution des fonctions. Les comportements de l’application de fonction s’appliquent à toutes les fonctions hébergées par l’application de fonction. Les fonctions d’une application de fonctions sont déployées ensemble et mises à l’échelle ensemble. Toutes les fonctions d’une application de fonction doivent être exprimées dans le même langage.

La manière dont vous regroupez les fonctions dans des applications de fonction peut affecter les performances et les capacités de mise à l’échelle de vos applications de fonction. Vous pouvez créer des groupes correspondant aux droits d’accès, au déploiement et aux schémas d’utilisation qui appellent votre code.

Pour obtenir de l’aide sur les meilleures pratiques concernant le regroupement et d’autres aspects de Fonctions, consultez Meilleures pratiques pour des Azure Functions fiables et Améliorer les performances et la fiabilité d’Azure Functions.

La liste suivante vous aidera à regrouper les fonctions. L’aide tient compte des aspects liés au stockage et aux groupes de consommateurs :

• Héberger une seule fonction dans une application de fonction : Si Event Hubs déclenche une fonction, vous pouvez isoler cette fonction dans son application afin de réduire les conflits avec les autres fonctions. L’isolation est particulièrement importante si les autres fonctions sont gourmandes en processeur ou en mémoire. Cette technique est utile car chaque fonction a sa propre empreinte mémoire et ses propres modèles d’utilisation qui peuvent directement affecter la mise à l’échelle de la fonction qui l’héberge.

• Attribuer à chaque application de fonction son propre compte de stockage : Évitez de partager des comptes de stockage entre les applications de fonction. De plus, si une application de fonction utilise un compte de stockage, n’utilisez pas ce compte pour effectuer d’autres opérations ou répondre à d’autres besoins de stockage. Il peut être particulièrement important d’éviter de partager des comptes de stockage pour les fonctions déclenchées par Event Hubs, car ces fonctions peuvent avoir un volume élevé de transactions de stockage en raison de points de contrôle.

• Créer un groupe de consommateurs dédié pour chaque application de fonction : Un groupe de consommateurs est un affichage d’un Event Hub. Étant donné que des groupes de consommateurs différents ont des affichages différents, les états, les positions et les décalages peuvent être différents. Les groupes de consommateurs permettent à plusieurs applications consommatrices d’avoir leurs propres affichages du flux d’événements et de le lire indépendamment. Chaque groupe peut lire le flux à son propre rythme et avec ses propres décalages. Pour plus d’informations sur les groupes de consommateurs, consultez Fonctionnalités et terminologie dans Azure Event Hubs.

  Un groupe de consommateurs est associé à une ou plusieurs applications de consommateurs, et une application de consommateurs peut utiliser un ou plusieurs groupes de consommateurs. Dans une solution de traitement des flux, chaque application de contrôle serveur consommateur équivaut à un groupe de consommateurs. Une application de fonction est un excellent exemple d’application grand public. L’illustration suivante présente un exemple de deux applications de fonction qui lisent à partir d’un Event Hub, où chaque application a son propre groupe de consommateurs dédié :

  

  Ne partagez pas de groupes de consommateurs entre des applications de fonction et d’autres applications grand public. Chaque application de fonction doit être une application distincte avec son propre groupe de consommateurs afin de garantir l’intégrité du décalage pour chaque contrôle serveur consommateur et de simplifier les dépendances dans une architecture de flux d’événements. Cette configuration, associée à l’attribution à chaque fonction déclenchée par un Event Hub de sa propre application de fonction et de son propre compte de stockage, permet de définir les fondements de performances et d’une mise à l’échelle optimales.

Plan d’hébergement de fonction

Il existe plusieurs options d’hébergement pour les applications de fonction et il est important d’examiner leurs fonctionnalités. Pour en savoir plus sur ces options d’hébergement, consultez Options d’hébergement Azure Functions. Notez la façon dont les options sont graduées.

Le plan par défaut est le plan Consommation. Les applications de fonction dans le plan Consommation sont mises à l’échelle indépendamment et sont plus efficaces lorsqu’elles évitent les tâches de longue durée.

Les plans Premium et Dedicated sont souvent utilisés pour héberger plusieurs fonctions et applications de fonction qui sont plus gourmandes en ressources processeur et en mémoire. Avec le plan Dedicated, vous exécutez vos fonctions dans un plan Azure App Service à des tarifs réguliers du plan App Service. Il est important de noter que toutes les applications de fonction de ces plans partagent les ressources qui sont allouées au plan. Si les fonctions ont des profils de charge différents ou des exigences uniques, il est préférable de les héberger dans des plans différents, en particulier dans les applications de traitement de flux.

Azure Container Apps fournit un support intégré pour le développement, le déploiement et la gestion d’applications de fonction conteneurisées sur Azure Functions. Vous pouvez ainsi exécuter vos fonctions pilotées par les événements dans un environnement entièrement géré, basé sur Kubernetes, avec une prise en charge intégrée de la supervision open source, mTLS, Dapr et KEDA.

Mise à l’échelle Event Hubs

Lorsque vous déployez un espace de noms Event Hubs, il existe plusieurs paramètres importants à définir correctement pour garantir des performances et une mise à l’échelle optimales. Cette section se concentre sur le niveau Standard d’Event Hubs et sur les caractéristiques uniques de ce niveau qui affectent la mise à l’échelle lorsque vous utilisez également des fonctions. Pour plus d’informations sur les niveaux d’Event Hubs, consultez Comparaison des niveaux De base, Standard, Premium et Dedicated.

Un espace de noms Event Hubs correspond à un cluster Kafka. Pour plus d’informations sur la relation entre Event Hubs et Kafka, consultez Utiliser Azure Event Hubs pour Apache Kafka.

Fonctionnement des unités de débit

Dans le niveau Standard d’Event Hubs, le débit est défini comme la quantité de données qui entrent et sont lues dans l’espace de noms par unité de temps. Les unités de débit sont des unités de capacité de débit achetées à l’avance.

Les unités de débit sont facturées à l’heure.

Tous les Event Hubs d’un espace de noms partagent les unités de débit. Pour calculer correctement les besoins en capacité, il faut tenir compte de toutes les applications et de tous les services, qu’ils soient éditeurs ou contrôle serveur consommateurs. Les fonctions affectent le nombre d’octets et d’événements qui sont publiés et lus à partir d’un Event Hub.

L’accent est mis sur le point d’entrée pour déterminer le nombre d’unités de débit. Toutefois, l’agrégat pour les applications grand public, y compris la vitesse à laquelle ces événements sont traités, doit également être inclus dans le calcul.

Pour plus d’informations sur les unités de débit Event Hubs, consultez Unités de débit.

Mise à l’échelle avec majoration automatique

La majoration automatique peut être activée sur un espace de noms Event Hubs pour répondre aux situations dans lesquelles la charge dépasse le nombre configuré d’unités de débit. L’utilisation de la majoration automatique empêche la limitation de votre application et permet de garantir que le traitement, y compris l’ingestion d’événements, se poursuit sans interruption. Étant donné que le paramètre d’unités de débit influe sur les coûts, l’utilisation de la majoration automatique permet de résoudre les problèmes de surapprovisionnement.

La majoration automatique est une fonctionnalité unique d’Event Hubs qui est souvent confondue avec la mise à l’échelle automatique, en particulier dans le contexte des solutions serverless. Toutefois, contrairement à la majoration automatique, la mise à l’échelle automatique n’est pas réduite lorsque la capacité ajoutée n’est plus nécessaire.

Si l’application a besoin d’une capacité supérieure au nombre maximum d’unités de débit autorisé, envisagez d’utiliser le niveau Premium ou le niveau Dedicated d’Event Hubs.

Partitions et fonctions simultanées

Après la création d’un Event Hub, le nombre de partitions doit être spécifié. Le nombre de partitions reste fixe et ne peut pas être modifié, sauf pour les niveaux Premium et Dedicated. Lorsque Event Hubs déclenche des applications de fonction, il est possible que le nombre d’instances simultanées soit égal au nombre de partitions.

Dans les plans d’hébergement Consommation et Premium, les instances des applications de fonction s’adaptent dynamiquement au nombre de partitions, si nécessaire. Le plan d’hébergement Dedicated exécute des fonctions dans un plan App Service et nécessite que vous configuriez manuellement vos instances ou que vous mettiez en place un schéma de mise à l’échelle automatique. Pour plus d’informations, consultez Plans d’hébergement Dedicated pour Azure Functions.

Enfin, une relation un-à-un entre le nombre de partitions et les instances d’application de fonction, ou de consommateurs, est la cible idéale pour un débit maximal dans une solution de traitement de flux. Pour obtenir un parallélisme optimal, il convient d’avoir plusieurs contrôle serveur consommateurs dans un groupe de consommateurs. Pour les fonctions, cet objectif se traduit par de nombreuses instances d’une fonction dans le plan. Le résultat est appelé parallélisme au niveau de la partition ou le degré maximal de parallélisme, tel qu’illustré dans le diagramme suivant :

Il peut être judicieux de configurer autant de partitions que possible pour atteindre un débit maximal et prendre en compte la possibilité d’un nombre d’événements plus élevé. Toutefois, plusieurs facteurs importants doivent être pris en compte lorsque vous configurez de nombreuses partitions :

• Plus de partitions peuvent entraîner plus de débit : Le degré de parallélisme étant le nombre de contrôle serveur consommateurs (instances fonctions), plus il y a de partitions, plus le débit simultané peut être élevé. Ce fait est important lors du partage d’un nombre désigné d’unités de débit pour un Event Hub avec d’autres applications de contrôle serveur consommateur.
• Plus de fonctions peuvent nécessiter plus de mémoire : Plus le nombre d’instances fonctions augmente, plus l’empreinte mémoire des ressources du plan est importante. À un moment donné, un trop grand nombre de partitions peut altérer les performances pour les contrôle serveur consommateurs.
• Il existe un risque de contre-pression de la part des services en aval : Plus le débit augmente, plus vous risquez de submerger les services en aval ou de subir une contre-pression de leur part. La répartition des contrôle serveur consommateurs doit être prise en compte lors de la considération des conséquences pour les ressources périphériques. Parmi les conséquences possibles figurent la limitation des autres services, la saturation du réseau et d’autres formes de contention des ressources.
• Les partitions peuvent contenir peu de données : La combinaison de nombreuses partitions et d’un faible volume d’événements peut conduire à une distribution éparse des données entre les partitions. Un plus petit nombre de partitions peut au contraire permettre d’améliorer les performances et l’utilisation des ressources.

Disponibilité et cohérence

Lorsqu’une clé ou un ID de partition n’est pas spécifié, Event Hubs achemine un événement entrant vers la partition disponible suivante. Cette pratique offre une grande disponibilité et permet d’augmenter le débit des contrôle serveur consommateurs.

Lorsqu’il est nécessaire de hiérarchiser un ensemble d’événements, le producteur d’événements peut spécifier qu’une partition particulière doit être utilisée pour tous les événements de l’ensemble. L’application de contrôle serveur consommateur qui lit la partition reçoit les événements dans leur ordre d’apparition. Ce compromis offre une cohérence, mais compromet la disponibilité. N’utilisez pas cette approche à moins que l’ordre des événements ne doive être conservé.

Pour Functions, le classement est effectué lorsque les événements sont publiés sur une partition particulière et qu’une fonction déclenchée par Event Hubs obtient un bail pour la même partition. La possibilité de configurer une partition avec la liaison de sortie Event Hubs n’est actuellement pas prise en charge. La meilleure approche consiste alors à utiliser l’un des Kit de développement logiciel (SDK) d’Event Hubs pour publier sur une partition spécifique.

Pour plus d’informations sur la prise en charge de la disponibilité et de la cohérence par Event Hubs, consultez Disponibilité et cohérence dans Event Hubs.

Déclencheur Event Hubs

Cette section est consacrée aux paramètres et aux considérations qui permettent d’optimiser les fonctions déclenchées par Event Hubs. Les facteurs incluent le traitement par lots, l’échantillonnage et les fonctionnalités connexes qui influencent le comportement de la liaison d’un déclencheur d’Event Hub.

Traitement par lots pour les fonctions déclenchées

Vous pouvez configurer les fonctions qu’un Event Hub déclenche pour traiter un lot d’événements ou un seul événement à la fois. Le traitement d’un lot d’événements peut être plus efficace lorsqu’il réduit certaines des surcharges liées aux appels de fonctions. À moins que vous n’ayez besoin de traiter un seul événement, votre fonction doit être configurée pour traiter plusieurs événements quand elle est appelée.

L’activation du traitement par lots pour la liaison de déclencheur Event Hubs varie en fonction des langues :

• JavaScript, Python et d’autres langages permettent le traitement par lots lorsque la propriété cardinalité est définie sur many dans le fichier function.json de la fonction.
• Dans C#, la cardinalité est configurée automatiquement lorsqu’un tableau est désigné pour le type dans l’attribut EventHubTrigger.

Pour plus d’informations sur l’activation du traitement par lots, consultez Déclencheur Azure Event Hubs pour Azure Functions.

Paramètres du déclencheur

Plusieurs paramètres de configuration dans le fichier host.json jouent un rôle clé dans les caractéristiques de performances de la liaison de déclencheur Event Hubs pour Azure Functions :

• maxEventBatchSize : Ce paramètre représente le nombre maximal d’événements que la fonction peut recevoir lorsqu’elle est appelée. Si le nombre d’événements reçus est inférieur à cette valeur, la fonction est toujours appelée avec autant d’événements que disponibles. Il n’est pas possible de fixer une taille minimale de lot.
• prefetchCount : le nombre de prérécupération est l’un des paramètres les plus importants lors de l’optimisation des performances. Le canal AMQP sous-jacent se réfère à cette valeur pour déterminer le nombre de messages à récupérer et à mettre en cache pour le client. Le nombre de prérécupération doit être supérieur ou égal à la valeur maxEventBatchSize et est généralement défini sur un multiple de celle-ci. Si elle est inférieure à la valeur du paramètre maxEventBatchSize, les performances peuvent être altérées.
• batchCheckpointFrequency: Lorsque votre fonction traite des lots, cette valeur détermine la vitesse à laquelle les points de contrôle sont créés. La valeur par défaut est 1, ce qui signifie qu’il existe un point de contrôle chaque fois qu’une fonction traite correctement un seul lot. Un point de contrôle est créé au niveau de la partition pour chaque lecteur du groupe de consommateurs. Pour plus d’informations sur l’influence de ce paramètre sur les relectures et les nouvelles tentatives d’événements, consultez Event hub triggered Azure function: Replays and Retries (billet de blog).

Effectuez plusieurs tests de performances pour déterminer les valeurs à définir pour la liaison de déclencheur. Nous vous recommandons de modifier les paramètres de manière incrémentielle et d’effectuer des mesures régulières afin d’affiner ces options. Les valeurs par défaut constituent un point de départ raisonnable pour la plupart des solutions de traitement des événements.

Points de contrôle

Les points de contrôle marquent ou valident les positions de lecteur dans une séquence d’événements de partition. Il incombe à l’hôte Functions d’effectuer des points de contrôle à mesure que les événements sont traités et que le paramètre de la fréquence de point de contrôle du lot est respecté. Pour plus d’informations sur les points de contrôle, consultez Fonctionnalités et terminologie dans Azure Event Hubs.

Les concepts suivants peuvent vous aider à comprendre la relation entre le point de contrôle et la manière dont votre fonction traite les événements :

• Les exceptions sont toujours prises en compte dans le succès de la fonction : Si le processus de la fonction ne se bloque pas pendant le traitement des événements, l’exécution de la fonction est considérée comme réussie, même si des exceptions se sont produites. Lorsque la fonction est terminée, l’hôte des fonctions évalue batchCheckpointFrequency. S’il est temps pour un point de contrôle, celui-ci sera créé, même en cas d’exception. Bien que celles-ci n’affectent pas les points de contrôle, vous devriez toujours procéder à leur vérification et à leur traitement de manière appropriée.
• La fréquence des lots est importante : Dans les solutions de flux d’événements à volume élevé, il peut être avantageux de modifier le paramètre batchCheckpointFrequency à une valeur supérieure à 1. En augmentant cette valeur, il est possible de réduire le taux de création de points de contrôle et, par conséquent, le nombre d’opérations d’E/S de stockage.
• Des réexécutions peuvent se produire : Chaque fois qu’une fonction est appelée avec la liaison de déclencheur Event Hubs, elle utilise le point de contrôle le plus récent pour déterminer où reprendre le traitement. Le décalage de chaque contrôle serveur consommateur est enregistré au niveau de la partition pour chaque groupe de consommateurs. Les réexécutions se produisent lorsqu’un point de contrôle n’a pas eu lieu lors du dernier appel de la fonction, et que celle-ci est appelée une nouvelle fois. Pour plus d’informations sur les doublons et les techniques de déduplication, consultez Idempotency.

La compréhension des points de contrôle devient essentielle lorsque vous examinez les meilleures pratiques pour la gestion des erreurs et les nouvelles tentatives. Ce sujet est abordé ultérieurement dans cet article.

Échantillonnage de la télémétrie

Les fonctions offrent une prise en charge intégrée d’Application Insights, une extension d’Azure Monitor qui permet la surveillance des performances des applications. Cette fonctionnalité permet d’enregistrer des informations sur les activités des fonctions, les performances, les exceptions d’exécution, etc. Pour plus d’informations, consultez Vue d’ensemble d’Application Insights.

Cette puissante capacité offre quelques choix de configuration clés qui influent sur les performances. Voici quelques-uns des paramètres et des considérations à prendre en compte pour la surveillance et les performances :

• Activer l’échantillonnage de télémétrie : pour les scénarios à débit élevé, vous devez évaluer la quantité de données de télémétrie et les informations dont vous avez besoin. Envisagez d’utiliser la fonctionnalité d’échantillonnage de la télémétrie dans Application Insights pour éviter de dégrader les performances de votre fonction avec de la télémétrie et des mesures inutiles.
• Configurer les paramètres d’agrégation : Examinez et configurez la fréquence d’agrégation et d’envoi des données à Application Insights. Ce paramètre de configuration se trouve dans le fichier host.json avec de nombreuses autres options d’échantillonnage et de journalisation. Pour plus d’informations, consultez Configurer l’agrégateur.
• Désactiver AzureWebJobDashboard : pour les applications qui ciblent la version 1.x du runtime Azure Functions, ce paramètre stocke la chaîne de connexion dans un compte de stockage utilisé par le Kit de développement logiciel (SDK) Azure pour conserver les journaux du tableau de bord de WebJobs. Si Application Insights est utilisé à la place du tableau de bord WebJobs, ce paramètre doit être supprimé. Pour plus d’informations, consultez AzureWebJobsDashboard.

Lorsque Application Insights est activé sans échantillonnage, toutes les données de télémétrie sont envoyées. L’envoi de données sur tous les événements peut avoir un effet négatif sur les performances de la fonction, en particulier dans les scénarios de flux d’événements à débit élevé.

Pour obtenir des performances optimales, il est essentiel de tirer parti de l’échantillonnage et d’évaluer en permanence la quantité de données de télémétrie nécessaire à la surveillance. La télémétrie doit être utilisée pour évaluer l’état général de la plateforme et pour des dépannages occasionnels, et non pour recueillir des mesures opérationnelles essentielles. Pour plus d’informations, consultez Configurer l’échantillonnage.

Liaison de sortie

Utilisez la liaison de sortie Event Hubs pour Azure Functions afin de simplifier la publication sur un flux d’événements à partir d’une fonction. Voici quelques-uns des avantages de l’utilisation de cette liaison :

• Gestion des ressources : La liaison gère pour vous les cycles de vie du client et de la connexion, et réduit les risques de problèmes liés à l’épuisement des ports et à la gestion du pool de connexions.
• Moins de code : La liaison fait abstraction du Kit de développement logiciel (SDK) sous-jacent et réduit la quantité de code nécessaire pour publier des événements. Cela vous permet de simplifier l’écriture et la maintenance du code.
• Traitement par lot : Le traitement par lot est pris en charge par plusieurs langages afin de permettre une publication efficace dans un flux d’événements. Cela permet d’améliorer les performances et contribue à rationaliser le code qui envoie les événements.

Nous vous recommandons vivement de consulter la liste des langages pris en charge par Azure Functions et les guides du développeur pour ces langages. La section Liaisons pour chaque langage fournit des exemples détaillés et de la documentation.

Traitement par lots lors de la publication d’événements

Si votre fonction ne publie qu’un seul événement, il est courant de configurer la liaison pour qu’elle renvoie une valeur, ce qui est utile si l’exécution de la fonction se termine toujours par une instruction qui envoie l’événement. Cette technique ne doit être utilisée que pour les fonctions synchrones qui ne renvoient qu’un seul événement.

Le traitement par lot est encouragé afin d’améliorer les performances lors de l’envoi de plusieurs événements à un flux. Le traitement par lot permet à la liaison de publier des événements de la manière la plus efficace possible.

La prise en charge de l’utilisation de la liaison de sortie pour envoyer plusieurs événements Event Hubs est disponible en C#, Java, Python et JavaScript.

Sortie de plusieurs événements avec le modèle in-process (C#)

Utilisez les types ICollector et IAsyncCollector lorsque vous envoyez plusieurs événements à partir d’une fonction en C#.

• La méthode ICollector<T>.Add() peut être utilisée dans les fonctions synchrones et asynchrones. Elle exécute l’opération d’ajout est exécutée dès qu’elle est appelée.
• La méthode IAsyncCollector<T>.AddAsync() prépare la publication des événements dans le flux d’événements. Si vous écrivez une fonction asynchrone, vous devez utiliser IAsyncCollector pour mieux gérer les événements publiés.

Pour obtenir des exemples d’utilisation de C# pour publier des événements uniques et multiples, consultez Liaison de sortie Azure Event Hubs pour Azure Functions.

Générer plusieurs événements avec le modèle worker Isolé (C#)

Selon la version du runtime Functions, le modèle worker Isolé prend en charge différents types pour les paramètres transférés à la liaison de sortie. Pour plusieurs événements, un tableau est utilisé pour encapsuler l’ensemble. Il est recommandé d’examiner les attributs de la liaison de sortie et les détails d’utilisation du modèle Isolé, et de noter les différences entre les versions d’extension.

Limitation et contre-pression

Les considérations relatives à la limitation s’appliquent également aux liaisons de sortie, non seulement pour Event Hubs mais aussi pour les services Azure, tels que Azure Cosmos DB. Il est important de se familiariser avec les limites et les quotas qui s’appliquent à ces services et de planifier en conséquence.

Pour gérer les erreurs en aval, avec le modèle In-process vous pouvez encapsuler AddAsync et FlushAsync dans un gestionnaire d’exceptions pour les fonctions .NET afin d’intercepter les exceptions de IAsyncCollector. Une autre option consiste à utiliser directement les Kit de développement logiciel (SDK) Event Hubs au lieu d’utiliser des liaisons de sortie.

Si vous exploitez le modèle Isolé pour les fonctions, il convient d’utiliser une gestion structurée des exceptions afin de détecter de manière responsable les exceptions lors du renvoi des valeurs de sortie.

Code de fonction

Cette section décrit les domaines clés qui doivent être pris en compte lors de l’écriture du code pour traiter les événements dans une fonction déclenchée par Event Hubs.

Programmation asynchrone

Nous vous recommandons d’écrire votre fonction pour utiliser du code asynchrone et éviter de bloquer les appels, en particulier lorsque des appels d’E/S sont impliqués.

Voici les instructions que vous devez suivre lorsque vous écrivez une fonction à traiter de manière asynchrone :

• Tout asynchrone ou tout synchrone : Si une fonction est configurée pour s’exécuter de manière asynchrone, tous les appels d’E/S doivent être asynchrones. Dans la plupart des cas, un code partiellement asynchrone est moins bon qu’un code entièrement synchrone. Choisissez asynchrone ou synchrone, puis respectez le choix tout au long.
• Évitez les appels bloquants : Les appels bloquants ne renvoient à l’appelant qu’une fois l’appel terminé, contrairement aux appels asynchrones qui y renvoient immédiatement. Un exemple dans C# serait d’appeler Task.Result ou Task.Wait sur une opération asynchrone.

En savoir plus sur les appels bloquants

L’utilisation d’appels bloquants pour des opérations asynchrones peut entraîner la saturation du pool de threads et provoquer le blocage du processus de la fonction. L’incident se produit parce qu’un appel bloquant nécessite la création d’un autre thread pour compenser l’appel original qui est maintenant en attente. Par conséquent, cette opération nécessite deux fois plus de threads pour être réalisée.

Il est particulièrement important d’éviter cette approche synchrone/asynchrone lorsque Event Hubs est impliqué, car un incident sur la fonction ne mettra pas à jour le point de contrôle. La prochaine fois que la fonction est invoquée, elle peut entrer dans ce cycle et donner l’impression d’être bloquée ou de progresser lentement, car les exécutions de la fonction finissent par s’arrêter.

Le dépannage de ce phénomène commence généralement par la revue des paramètres du déclencheur et l’exécution des expériences qui peuvent impliquer l’augmentation du nombre de partitions. Les investigations peuvent également entraîner la modification de plusieurs options de traitement par lot, telles que la taille de lot maximale ou le nombre de prérécupérations. Il semble qu’il s’agisse d’un problème de débit ou d’un paramètre de configuration qui doit simplement être réglé en conséquence. Toutefois, le problème principal se trouve dans le code lui-même et doit être résolu à ce niveau.

Contributeurs

Cet article est géré par Microsoft. Il a été écrit à l’origine par les contributeurs suivants.

Auteur principal :

• David Barkol | PSS (Principal Solution Specialist) (GBB)

Pour afficher les profils LinkedIn non publics, connectez-vous à LinkedIn.

Étapes suivantes

Avant de continuer, consultez les articles suivants :

• Surveiller les exécutions dans Azure Functions
• Traitement des événements fiables Azure Functions
• Conception d’Azure Functions pour une entrée identique
• Guide sur les opérations asynchrones dans ASP.NET Core
• Déclencheur Azure Event Hubs pour Azure Functions

Ressource associée

• Traitement d’événements serverless