Bewerken

Delen via


Richtlijnen voor prestaties en schaal voor Event Hubs en Azure Functions

Azure Event Hubs
Azure Functions

Dit artikel bevat richtlijnen voor het optimaliseren van schaalbaarheid en prestaties wanneer u Azure Event Hubs en Azure Functions samen in uw toepassingen gebruikt.

Functiegroepering

Normaal gesproken bevat een functie een werkeenheid in een gebeurtenisverwerkingsstroom. Een functie kan bijvoorbeeld een gebeurtenis transformeren in een nieuwe gegevensstructuur of gegevens verrijken voor downstreamtoepassingen.

In Functions biedt een functie-app de uitvoeringscontext voor functies. Gedrag van de functie-app is van toepassing op alle functies die door de functie-app worden gehost. Functies in een functie-app worden samen geïmplementeerd en samen geschaald. Alle functies in een functie-app moeten dezelfde taal hebben.

Hoe u functies in functie-apps groepeert, kan van invloed zijn op de prestaties en schaalmogelijkheden van uw functie-apps. U kunt groeperen op basis van toegangsrechten, implementatie en de gebruikspatronen die uw code aanroepen.

Zie Best practices voor betrouwbare Azure Functions en verbeter de prestaties en betrouwbaarheid van Azure Functions voor hulp bij aanbevolen procedures voor functies voor groepering en andere aspecten.

De volgende lijst bevat richtlijnen voor het groeperen van functies. In de richtlijnen worden aspecten van opslag- en consumentengroepen in overweging gebracht:

  • Host één functie in een functie-app: Als Event Hubs een functie activeert, kunt u, om conflicten tussen die functie en andere functies te verminderen, de functie isoleren in een eigen functie-app. Isolatie is vooral belangrijk als de andere functies CPU of geheugenintensief zijn. Deze techniek helpt omdat elke functie een eigen geheugenvoetafdruk en gebruikspatronen heeft die rechtstreeks van invloed kunnen zijn op het schalen van de functie-app die deze host.

  • Geef elke functie-app een eigen opslagaccount: Vermijd het delen van opslagaccounts tussen functie-apps. Als een functie-app gebruikmaakt van een opslagaccount, gebruikt u dat account niet voor andere opslagbewerkingen of -behoeften. Het kan met name belangrijk zijn om te voorkomen dat opslagaccounts worden gedeeld voor functies die Event Hubs activeert, omdat dergelijke functies een groot aantal opslagtransacties kunnen hebben vanwege controlepunten.

  • Maak een speciale consumentengroep voor elke functie-app: een consumentengroep is een weergave van een Event Hub. Verschillende consumentengroepen hebben verschillende weergaven, wat betekent dat de statussen, posities en offsets kunnen verschillen. Consumentengroepen maken het mogelijk voor meerdere toepassingen om hun eigen weergaven van de gebeurtenisstroom te hebben en om de stream onafhankelijk in hun eigen tempo en met hun eigen offsets te lezen. Zie Functies en terminologie in Azure Event Hubs voor meer informatie over consumentengroepen.

    Aan een consumentengroep zijn een of meer consumententoepassingen gekoppeld en een consumententoepassing kan een of meer consumentengroepen gebruiken. In een stroomverwerkingsoplossing is elke consumententoepassing gelijk aan een consumentengroep. Een functie-app is een uitstekend voorbeeld van een consumententoepassing. In het volgende diagram ziet u een voorbeeld van twee functie-apps die worden gelezen uit een Event Hub, waarbij elke app een eigen toegewezen consumentengroep heeft:

    Toegewezen consumentengroepen voor elke functie-app

    Deel geen consumentengroepen tussen functie-apps en andere consumententoepassingen. Elke functie-app moet een afzonderlijke toepassing zijn met een eigen toegewezen consumentengroep om de offsetintegriteit voor elke consument te waarborgen en afhankelijkheden in een gebeurtenisstreamingarchitectuur te vereenvoudigen. Een dergelijke configuratie, samen met het bieden van elke door de Event Hub geactiveerde functie een eigen functie-app en opslagaccount, helpt de basis voor optimale prestaties en schalen.

Hostingplannen voor functies

Er zijn verschillende hostingopties voor functie-apps en het is belangrijk om hun mogelijkheden te controleren. Zie Azure Functions-hostingopties voor meer informatie over deze hostingopties. Noteer hoe de opties worden geschaald.

Het verbruiksabonnement is de standaardinstelling. Functie-apps in het verbruiksplan worden onafhankelijk geschaald en zijn het meest effectief wanneer ze langlopende taken vermijden.

De Premium- en Dedicated-abonnementen worden vaak gebruikt om meerdere functie-apps en -functies te hosten die meer CPU- en geheugenintensief zijn. Met het Dedicated-plan voert u uw functies uit in een Azure-app Service-plan tegen normale tarieven voor App Service-plannen. Het is belangrijk te weten dat alle functie-apps in deze plannen de resources delen die aan het plan zijn toegewezen. Als functies verschillende belastingprofielen of unieke vereisten hebben, kunt u ze het beste hosten in verschillende plannen, met name in toepassingen voor stroomverwerking.

Azure Container Apps biedt geïntegreerde ondersteuning voor het ontwikkelen, implementeren en beheren van containerfunctie-apps in Azure Functions. Hiermee kunt u uw gebeurtenisgestuurde functies uitvoeren in een volledig beheerde, kubernetes-omgeving met ingebouwde ondersteuning voor opensource-bewaking, mTLS, Dapr en KEDA.

Event Hubs schalen

Wanneer u een Event Hubs-naamruimte implementeert, zijn er verschillende belangrijke instellingen die u correct moet instellen om piekprestaties en schalen te garanderen. Deze sectie is gericht op de Standard-laag van Event Hubs en de unieke functies van die laag die van invloed zijn op schalen wanneer u ook Functions gebruikt. Zie Basic versus Standard versus Premium versus Dedicated-lagen voor meer informatie over Event Hubs-lagen.

Een Event Hubs-naamruimte komt overeen met een Kafka-cluster. Zie Wat is Azure Event Hubs voor Apache Kafka voor meer informatie over hoe Event Hubs en Kafka met elkaar zijn verbonden.

Informatie over doorvoereenheden (RU's)

In de Event Hubs Standard-laag wordt doorvoer geclassificeerd als de hoeveelheid gegevens die wordt ingevoerd en wordt gelezen uit de naamruimte per tijdseenheid. TU's zijn vooraf aangeschafte eenheden van doorvoercapaciteit.

DEU's worden per uur gefactureerd.

Alle Event Hubs in een naamruimte delen de TU's. Als u de capaciteitsbehoeften goed wilt berekenen, moet u rekening houden met alle toepassingen en services, zowel uitgevers als consumenten. Functies zijn van invloed op het aantal bytes en gebeurtenissen dat is gepubliceerd naar en gelezen vanuit een Event Hub.

De nadruk voor het bepalen van het aantal TU's ligt op het punt van inkomend verkeer. De statistische functie voor de consumententoepassingen, inclusief de snelheid waarmee deze gebeurtenissen worden verwerkt, moet echter ook worden opgenomen in de berekening.

Zie Doorvoereenheden voor Event Hubs voor meer informatie.

Omhoog schalen met automatisch vergroten

Automatisch vergroten kan worden ingeschakeld in een Event Hubs-naamruimte voor situaties waarin de belasting het geconfigureerde aantal TU's overschrijdt. Door automatisch inflate te gebruiken, voorkomt u beperking van uw toepassing en zorgt u ervoor dat de verwerking, inclusief het opnemen van gebeurtenissen, zonder onderbreking wordt voortgezet. Omdat de TU-instelling van invloed is op de kosten, helpt het gebruik van automatische inflate ondersteuning bij het oplossen van zorgen over overprovisioning.

Automatisch vergroten is een functie van Event Hubs die vaak wordt verward met automatische schaalaanpassing, met name in de context van serverloze oplossingen. Automatisch vergroten, in tegenstelling tot automatisch schalen, wordt echter niet omlaag geschaald wanneer toegevoegde capaciteit niet meer nodig is.

Als de toepassing capaciteit nodig heeft die het maximaal toegestane aantal TU's overschrijdt, kunt u overwegen om de Premium-laag of de Dedicated-laag van Event Hubs te gebruiken.

Partities en gelijktijdige functies

Wanneer een Event Hub wordt gemaakt, moet het aantal partities worden opgegeven. Het aantal partities blijft vast en kan niet worden gewijzigd, behalve van de Premium- en Dedicated-lagen. Wanneer Event Hubs functions-apps activeert, is het mogelijk dat het aantal gelijktijdige exemplaren gelijk is aan het aantal partities.

In verbruiks- en Premium-hostingabonnementen worden de instanties van de functie-app dynamisch uitgeschaald om zo nodig te voldoen aan het aantal partities. Het Dedicated Hosting-plan voert functies uit in een App Service-plan en vereist dat u uw exemplaren handmatig configureert of een schema voor automatische schaalaanpassing instelt. Zie Dedicated-hostingabonnementen voor Azure Functions voor meer informatie.

Uiteindelijk is een een-op-een-relatie tussen het aantal partities en functie-exemplaren, of consumenten, het ideale doel voor maximale doorvoer in een stroomverwerkingsoplossing. Als u optimaal parallellisme wilt bereiken, moet u meerdere consumenten in een consumentengroep hebben. Voor Functions wordt deze doelstelling omgezet in veel exemplaren van een functie in het plan. Het resultaat wordt aangeduid als parallellisme op partitieniveau of de maximale mate van parallelle uitvoering, zoals wordt weergegeven in het volgende diagram:

Maximale mate van parallelle uitvoering

Het lijkt misschien zinvol om zoveel mogelijk partities te configureren om maximale doorvoer te bereiken en rekening te houden met de mogelijkheid van een groter aantal gebeurtenissen. Er zijn echter verschillende belangrijke factoren die u moet overwegen wanneer u veel partities configureert:

  • Meer partities kunnen leiden tot meer doorvoer: omdat de mate van parallelle uitvoering het aantal consumenten (functie-exemplaren) is, hoe meer partities er zijn, hoe hoger de gelijktijdige doorvoer kan zijn. Dit is belangrijk wanneer u een aangewezen aantal TU's deelt voor een Event Hub met andere consumententoepassingen.
  • Meer functies kunnen meer geheugen vereisen: naarmate het aantal functie-exemplaren toeneemt, neemt de geheugenvoetafdruk van resources in het plan toe. Op een bepaald moment kunnen te veel partities de prestaties voor consumenten verslechteren.
  • Er bestaat een risico op terugdruk van downstreamservices: naarmate er meer doorvoer wordt gegenereerd, loopt u het risico op overweldigende downstreamservices of het ontvangen van een terugdruk van deze services. De consument moet rekening houden met de gevolgen van de omringende resources. Mogelijke gevolgen zijn beperking van andere services, netwerkverzadiging en andere vormen van resourceconflicten.
  • Partities kunnen parsgedeeld worden: de combinatie van veel partities en een laag aantal gebeurtenissen kan leiden tot gegevens die parserend over partities worden gedistribueerd. In plaats daarvan kan een kleiner aantal partities betere prestaties en resourcegebruik bieden.

Beschikbaarheid en consistentie

Wanneer er geen partitiesleutel of id is opgegeven, stuurt Event Hubs een binnenkomende gebeurtenis naar de volgende beschikbare partitie. Deze procedure biedt hoge beschikbaarheid en helpt de doorvoer voor consumenten te verhogen.

Wanneer de volgorde van een reeks gebeurtenissen is vereist, kan de gebeurtenisproducent opgeven dat een bepaalde partitie moet worden gebruikt voor alle gebeurtenissen van de set. De consumententoepassing die van de partitie leest, ontvangt de gebeurtenissen in de juiste volgorde. Dit compromis biedt consistentie, maar compromissen met de beschikbaarheid. Gebruik deze methode alleen als de volgorde van gebeurtenissen behouden moet blijven.

Voor Functions wordt volgorde bereikt wanneer gebeurtenissen worden gepubliceerd naar een bepaalde partitie en een door Event Hubs geactiveerde functie een lease voor dezelfde partitie verkrijgt. Momenteel wordt de mogelijkheid om een partitie te configureren met de Event Hubs-uitvoerbinding niet ondersteund. In plaats daarvan kunt u het beste een van de Event Hubs SDK's gebruiken om naar een specifieke partitie te publiceren.

Zie Beschikbaarheid en consistentie in Event Hubs voor meer informatie over hoe Event Hubs beschikbaarheid en consistentie ondersteunt.

Event Hubs-trigger

Deze sectie is gericht op de instellingen en overwegingen voor het optimaliseren van functies die Event Hubs activeert. Factoren zijn onder andere batchverwerking, steekproeven en gerelateerde functies die van invloed zijn op het gedrag van een Event Hub-triggerbinding.

Batchverwerking voor geactiveerde functies

U kunt functies configureren die door een Event Hub worden geactiveerd om een batch gebeurtenissen of één gebeurtenis tegelijk te verwerken. Het verwerken van een batch gebeurtenissen kan efficiënter zijn wanneer een deel van de overhead van functie-aanroepen wordt verminderd. Tenzij u slechts één gebeurtenis moet verwerken, moet uw functie worden geconfigureerd voor het verwerken van meerdere gebeurtenissen wanneer deze wordt aangeroepen.

Het inschakelen van batchverwerking voor de Event Hubs-triggerbinding verschilt per taal:

  • JavaScript, Python en andere talen maken batchverwerking mogelijk wanneer de eigenschap kardinaliteit is ingesteld op veel in het function.json-bestand voor de functie.
  • In C# wordt kardinaliteit automatisch geconfigureerd wanneer een matrix wordt aangewezen voor het type in het kenmerk EventHubTrigger.

Zie De Azure Event Hubs-trigger voor Azure Functions voor meer informatie over hoe batchverwerking is ingeschakeld.

Triggerinstellingen

Verschillende configuratie-instellingen in het bestand host.json spelen een belangrijke rol in de prestatiekenmerken van de Event Hubs-triggerbinding voor Functions:

  • maxEventBatchSize: Deze instelling vertegenwoordigt het maximum aantal gebeurtenissen dat de functie kan ontvangen wanneer deze wordt aangeroepen. Als het aantal ontvangen gebeurtenissen kleiner is dan dit bedrag, wordt de functie nog steeds aangeroepen met zoveel gebeurtenissen als beschikbaar zijn. U kunt geen minimale batchgrootte instellen.
  • prefetchCount: Het aantal prefetchs is een van de belangrijkste instellingen wanneer u optimaliseert voor prestaties. Het onderliggende AMQP-kanaal verwijst naar deze waarde om te bepalen hoeveel berichten moeten worden opgehaald en in de cache voor de client moeten worden opgeslagen. Het aantal prefetchs moet groter zijn dan of gelijk zijn aan de waarde maxEventBatchSize en wordt meestal ingesteld op een veelvoud van dat bedrag. Als u deze waarde instelt op een getal kleiner dan de instelling maxEventBatchSize, kan dit de prestaties schaden.
  • batchCheckpointFrequency: Wanneer uw functie batches verwerkt, bepaalt deze waarde de snelheid waarmee controlepunten worden gemaakt. De standaardwaarde is 1, wat betekent dat er een controlepunt is wanneer een functie één batch verwerkt. Er wordt een controlepunt gemaakt op partitieniveau voor elke lezer in de consumentengroep. Zie De door Event Hub geactiveerde Azure-functie: Herhalingen en nieuwe pogingen (blogpost) voor informatie over hoe deze instelling van invloed is op herhalingen en nieuwe pogingen van gebeurtenissen.

Voer verschillende prestatietests uit om de waarden te bepalen die moeten worden ingesteld voor de triggerbinding. U wordt aangeraden de instellingen incrementeel te wijzigen en consistent te meten om deze opties nauwkeurig af te stemmen. De standaardwaarden zijn een redelijk startpunt voor de meeste oplossingen voor gebeurtenisverwerking.

Controlepunten maken

Controlepunten markeren of lezerposities doorvoeren in een partitie-gebeurtenisreeks. Het is de verantwoordelijkheid van de Functions-host om het controlepunt te controleren wanneer gebeurtenissen worden verwerkt en de instelling voor de frequentie van het batchcontrolepunt wordt voldaan. Zie Functies en terminologie in Azure Event Hubs voor meer informatie over controlepunten.

De volgende concepten kunnen u helpen inzicht te verkrijgen in de relatie tussen controlepunten en de manier waarop uw functie gebeurtenissen verwerkt:

  • Uitzonderingen tellen nog steeds mee voor succes: als het functieproces niet vastloopt tijdens het verwerken van gebeurtenissen, wordt de voltooiing van de functie beschouwd als geslaagd, zelfs als er uitzonderingen zijn opgetreden. Wanneer de functie is voltooid, evalueert de Functions-host batchCheckpointFrequency. Als het tijd is voor een controlepunt, wordt er een gemaakt, ongeacht of er uitzonderingen zijn. Het feit dat uitzonderingen geen invloed hebben op controlepunten, mag geen invloed hebben op uw juiste gebruik van uitzonderingscontrole en -verwerking.
  • Batchfrequentie is belangrijk: In oplossingen voor gebeurtenisstreaming met een hoog volume kan het handig zijn om de instelling batchCheckpointFrequency te wijzigen in een waarde die groter is dan 1. Door deze waarde te verhogen, kan de snelheid van het maken van controlepunten worden verminderd en kan het aantal I/O-bewerkingen voor opslag als gevolg hiervan worden verminderd.
  • Herhalingen kunnen zich voordoen: telkens wanneer een functie wordt aangeroepen met de Event Hubs-triggerbinding, wordt het meest recente controlepunt gebruikt om te bepalen waar de verwerking moet worden hervat. De offset voor elke consument wordt op het partitieniveau voor elke consumentengroep opgeslagen. Herhalingen gebeuren wanneer er geen controlepunt plaatsvindt tijdens de laatste aanroep van de functie en de functie opnieuw wordt aangeroepen. Zie Idempotentie voor meer informatie over duplicaten en ontdubbelingstechnieken.

Inzicht in controlepunten wordt essentieel wanneer u de aanbevolen procedures voor foutafhandeling en nieuwe pogingen overweegt, een onderwerp dat verderop in dit artikel wordt besproken.

Telemetriesampling

Functions biedt ingebouwde ondersteuning voor Application Insights, een uitbreiding van Azure Monitor die mogelijkheden biedt voor het bewaken van toepassingsprestaties. Met deze functie kunt u informatie vastleggen over functieactiviteiten, prestaties, runtime-uitzonderingen en meer. Zie Application Insights-overzicht voor meer informatie.

Deze krachtige mogelijkheid biedt enkele belangrijke configuratieopties die van invloed zijn op de prestaties. Enkele van de belangrijke instellingen en overwegingen voor bewaking en prestaties zijn:

  • Telemetriesampling inschakelen: voor scenario's met hoge doorvoer moet u de hoeveelheid telemetrie en informatie evalueren die u nodig hebt. Overweeg het gebruik van de functie voor telemetriesampling in Application Insights om te voorkomen dat de prestaties van uw functie afnemen met onnodige telemetrie en metrische gegevens.
  • Aggregatie-instellingen configureren: de frequentie van het samenvoegen en verzenden van gegevens naar Application Insights onderzoeken en configureren. Deze configuratie-instelling bevindt zich in het host.json-bestand , samen met veel andere opties voor steekproeven en logboekregistratie. Zie De aggregator configureren voor meer informatie.
  • Schakel AzureWebJobDashboard uit: voor apps die gericht zijn op versie 1.x van de Functions-runtime, wordt met deze instelling het verbindingsreeks opgeslagen in een opslagaccount dat door de Azure SDK wordt gebruikt om logboeken voor het WebJobs-dashboard te bewaren. Als Application Insights wordt gebruikt in plaats van het webtaakdashboard, moet deze instelling worden verwijderd. Zie AzureWebJobsDashboard voor meer informatie.

Wanneer Application Insights is ingeschakeld zonder steekproeven, worden alle telemetriegegevens verzonden. Het verzenden van gegevens over alle gebeurtenissen kan een nadelig effect hebben op de prestaties van de functie, met name onder scenario's voor gebeurtenisstreaming met hoge doorvoer.

Het gebruik van steekproeven en het voortdurend beoordelen van de juiste hoeveelheid telemetrie die nodig is voor bewaking, is van cruciaal belang voor optimale prestaties. Telemetrie moet worden gebruikt voor algemene platformstatusevaluatie en voor incidentele probleemoplossing, niet voor het vastleggen van belangrijke zakelijke metrische gegevens. Zie Sampling configureren voor meer informatie.

Uitvoerbinding

Gebruik de Event Hubs-uitvoerbinding voor Azure Functions om het publiceren naar een gebeurtenisstroom vanuit een functie te vereenvoudigen. De voordelen van het gebruik van deze binding zijn:

  • Resourcebeheer: De binding verwerkt zowel de levenscyclus van de client als de verbindingscyclus voor u en vermindert het potentieel voor problemen die kunnen optreden met poortuitputting en beheer van verbindingsgroepen.
  • Minder code: De binding abstraheert de onderliggende SDK en vermindert de hoeveelheid code die u nodig hebt om gebeurtenissen te publiceren. Hiermee kunt u code schrijven die gemakkelijker te schrijven en te onderhouden is.
  • Batchverwerking: Voor verschillende talen wordt batchverwerking ondersteund om efficiënt te publiceren naar een gebeurtenisstroom. Batchverwerking kan de prestaties verbeteren en helpen bij het stroomlijnen van de code die de gebeurtenissen verzendt.

We raden u ten zeerste aan de lijst met talen te bekijken die door Functions worden ondersteund en de ontwikkelaarshandleidingen voor deze talen. De sectie Bindingen voor elke taal bevat gedetailleerde voorbeelden en documentatie.

Batchverwerking bij het publiceren van gebeurtenissen

Als uw functie slechts één gebeurtenis publiceert, is het configureren van de binding om een waarde te retourneren een algemene benadering die handig is als de uitvoering van de functie altijd eindigt met een instructie waarmee de gebeurtenis wordt verzonden. Deze techniek mag alleen worden gebruikt voor synchrone functies die slechts één gebeurtenis retourneren.

Batchverwerking wordt aangemoedigd om de prestaties te verbeteren bij het verzenden van meerdere gebeurtenissen naar een stream. Met batchverwerking kan de binding gebeurtenissen op de meest efficiënte manier publiceren.

Ondersteuning voor het gebruik van de uitvoerbinding voor het verzenden van meerdere gebeurtenissen naar Event Hubs is beschikbaar in C#, Java, Python en JavaScript.

Meerdere gebeurtenissen uitvoeren met het in-procesmodel (C#)

Gebruik de typen ICollector en IAsyncCollector wanneer u meerdere gebeurtenissen vanuit een functie in C# verzendt.

  • De ICollector<T>. De methode Add() kan worden gebruikt in zowel synchrone als asynchrone functies. De bewerking voor toevoegen wordt uitgevoerd zodra deze wordt aangeroepen.
  • De IAsyncCollector<T>. Met de methode AddAsync() worden de gebeurtenissen voorbereid die naar de gebeurtenisstroom moeten worden gepubliceerd. Als u een asynchrone functie schrijft, moet u IAsyncCollector gebruiken om de gepubliceerde gebeurtenissen beter te beheren.

Zie Azure Event Hubs-uitvoerbinding voor Azure Functions voor voorbeelden van het gebruik van C# om één en meerdere gebeurtenissen te publiceren.

Meerdere gebeurtenissen uitvoeren met het Isolated Worker-model (C#)

Afhankelijk van de runtimeversie van Functions ondersteunt het geïsoleerde werkrolmodel verschillende typen voor de parameters die worden doorgegeven aan de uitvoerbinding. Voor meerdere gebeurtenissen wordt een matrix gebruikt om de set in te kapselen. Het wordt aanbevolen om de uitvoerbindingskenmerken en gebruiksgegevens voor het geïsoleerde model te controleren en de verschillen tussen de extensieversies te noteren.

Beperking en rugdruk

Beperkingsoverwegingen zijn van toepassing op uitvoerbindingen, niet alleen voor Event Hubs, maar ook voor Azure-services zoals Azure Cosmos DB. Het is belangrijk om vertrouwd te raken met de limieten en quota die van toepassing zijn op deze services en om dienovereenkomstig te plannen.

Als u downstreamfouten wilt verwerken met het in-procesmodel, kunt u AddAsync en FlushAsync verpakken in een uitzonderingshandler voor .NET Functions om uitzonderingen van IAsyncCollector te ondervangen. Een andere optie is om de Event Hubs SDK's rechtstreeks te gebruiken in plaats van uitvoerbindingen te gebruiken.

Als u gebruikmaakt van het geïsoleerde model voor functies, moet gestructureerde uitzonderingsafhandeling worden gebruikt om op verantwoorde wijze uitzonderingen te ondervangen bij het retourneren van de uitvoerwaarden.

Functiecode

In deze sectie worden de belangrijkste gebieden besproken die moeten worden overwogen bij het schrijven van code voor het verwerken van gebeurtenissen in een functie die door Event Hubs wordt geactiveerd.

Asynchroon programmeren

U wordt aangeraden uw functie te schrijven om asynchrone code te gebruiken en te voorkomen dat aanroepen worden geblokkeerd, met name wanneer er I/O-aanroepen betrokken zijn.

Hier volgen richtlijnen die u moet volgen wanneer u een functie schrijft om asynchroon te verwerken:

  • Asynchroon of allemaal synchroon: als een functie is geconfigureerd om asynchroon te worden uitgevoerd, moeten alle I/O-aanroepen asynchroon zijn. In de meeste gevallen is gedeeltelijk asynchrone code slechter dan code die volledig synchroon is. Kies asynchroon of synchroon en houd de keuze helemaal door.
  • Blokkeren van oproepen voorkomen: oproepen blokkeren keert pas terug naar de beller nadat de oproep is voltooid, in tegenstelling tot asynchrone oproepen die onmiddellijk worden geretourneerd. Een voorbeeld in C# is het aanroepen van Task.Result of Task.Wait op een asynchrone bewerking.

Meer informatie over het blokkeren van oproepen

Het gebruik van blokkerende aanroepen voor asynchrone bewerkingen kan leiden tot starvatie van thread-pool en ervoor zorgen dat het functieproces vastloopt. De crash treedt op omdat voor een blokkeringsoproep een andere thread moet worden gemaakt om te compenseren voor de oorspronkelijke oproep die nu wacht. Als gevolg hiervan zijn twee keer zoveel threads nodig om de bewerking te voltooien.

Het vermijden van deze synchronisatie via asynchrone benadering is vooral belangrijk wanneer Event Hubs betrokken is, omdat een functiecrash het controlepunt niet bijwerkt. De volgende keer dat de functie wordt aangeroepen, kan deze in deze cyclus terechtkomen en lijkt deze vast te zitten of langzaam te lopen als er uiteindelijk een time-out optreedt voor de uitvoering van de functie.

Het oplossen van dit fenomeen begint meestal met het controleren van de triggerinstellingen en het uitvoeren van experimenten waarbij het aantal partities kan worden verhoogd. Onderzoeken kunnen ook leiden tot het wijzigen van verschillende batchopties, zoals de maximale batchgrootte of het aantal prefetchs. De indruk is dat het een doorvoerprobleem of configuratie-instelling is die alleen dienovereenkomstig moet worden afgestemd. Het kernprobleem bevindt zich echter in de code zelf en moet daar worden opgelost.

Medewerkers

Dit artikel wordt onderhouden door Microsoft. Het is oorspronkelijk geschreven door de volgende inzender.

Hoofdauteur:

Als u niet-openbare LinkedIn-profielen wilt zien, meldt u zich aan bij LinkedIn.

Volgende stappen

Voordat u verdergaat, kunt u de volgende gerelateerde artikelen bekijken: