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 omvat 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. Het 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 in dezelfde taal zijn.
Hoe u functies in functie-apps groepeert, kan van invloed zijn op de prestaties en schaalmogelijkheden van uw functie-apps. U kunt groepeer op basis van toegangsrechten, implementatie en de gebruikspatronen die uw code aanroepen.
Zie Aanbevolen procedures voor betrouwbare Azure Functions en De prestaties en betrouwbaarheid van Azure Functions verbeteren voor richtlijnen over best practices voor Functions voor groepering en andere aspecten.
De volgende lijst bevat richtlijnen voor het groeperen van functies. In de richtlijnen wordt rekening gehouden met de aspecten van opslag en consumentengroepen:
Eén functie hosten 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 de eigen functie-app. Isolatie is vooral belangrijk als de andere functies CPU- of geheugenintensief zijn. Deze techniek helpt omdat elke functie zijn eigen geheugenvoetafdruk en gebruikspatronen heeft die rechtstreeks van invloed kunnen zijn op de schaal van de functie-app die als host fungeert.
Geef elke functie-app een eigen opslagaccount: Vermijd het delen van opslagaccounts tussen functie-apps. Als een functie-app gebruikmaakt van een opslagaccount, moet u dat account ook niet gebruiken voor andere opslagbewerkingen of -behoeften. Het kan vooral belangrijk zijn om te voorkomen dat opslagaccounts worden gedeeld voor functies die door Event Hubs worden geactiveerd, omdat dergelijke functies een groot aantal opslagtransacties kunnen hebben vanwege controlepunten.
Maak een toegewezen 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 verschuivingen kunnen verschillen. Consumentengroepen maken het mogelijk voor meerdere verbruikende toepassingen om hun eigen weergaven van de gebeurtenisstroom te hebben en om de stream onafhankelijk te lezen in hun eigen tempo en met hun eigen offsets. 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 oplossing voor stroomverwerking is elke consumententoepassing gelijk aan een consumentengroep. Een functie-app is een uitstekend voorbeeld van een consumententoepassing. Het volgende diagram bevat een voorbeeld van twee functie-apps die worden gelezen uit een Event Hub, waarbij elke app een eigen toegewezen consumentengroep heeft:
Deel geen consumentengroepen tussen functie-apps en andere consumententoepassingen. Elke functie-app moet een afzonderlijke toepassing zijn met een eigen toegewezen consumentengroep om offset-integriteit voor elke consument te garanderen en om afhankelijkheden in een gebeurtenisstreamingarchitectuur te vereenvoudigen. Een dergelijke configuratie, samen met het bieden van een door event hub geactiveerde functie een eigen functie-app en opslagaccount, helpt bij het instellen van de basis voor optimale prestaties en schaalaanpassing.
Functiehostingabonnementen
Elke functie-app wordt gehost volgens een van de drie hostingabonnementen. Zie Azure Functions hostingopties voor meer informatie over deze abonnementen. Let op hoe de drie opties worden geschaald.
Het verbruiksabonnement is de standaardinstelling. Functie-apps in het verbruiksabonnement worden onafhankelijk geschaald en zijn het meest effectief wanneer ze langdurige taken vermijden.
De Premium- en Dedicated-abonnementen worden vaak gebruikt voor het hosten van meerdere functie-apps en functies die meer CPU- en geheugenintensief zijn. Met het Dedicated-abonnement voert u uw functies uit in een Azure App Service-plan tegen normale App Service-abonnementstarieven. 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 deze het beste in verschillende plannen hosten, met name in toepassingen voor stroomverwerking.
Event Hubs schalen
Wanneer u een Event Hubs-naamruimte implementeert, zijn er verschillende belangrijke instellingen die u goed 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 het schalen wanneer u ook Functions gebruikt. Zie Basic vs. Standard vs. Premium vs. Dedicated tiers (Basic vs. Standard vs. Premium vs. Dedicated tiers) 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 informatie over de relatie tussen Event Hubs en Kafka.
Informatie over doorvoereenheden (TU's)
In de Standard-laag van Event Hubs 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.
TU's worden op uurbasis 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 wordt gepubliceerd naar en gelezen vanuit een Event Hub.
De nadruk bij het bepalen van het aantal TU's ligt op het punt van inkomend verkeer. De aggregatie voor de consumententoepassingen, inclusief de snelheid waarmee deze gebeurtenissen worden verwerkt, moet echter ook worden opgenomen in de berekening.
Zie Doorvoereenheden voor meer informatie over Doorvoereenheden van Event Hubs.
Omhoog schalen met automatisch vergroten
Automatisch vergroten kan worden ingeschakeld voor een Event Hubs-naamruimte voor situaties waarin de belasting het geconfigureerde aantal TU's overschrijdt. Het gebruik van Automatisch vergroten voorkomt beperking van uw toepassing en zorgt 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 Automatisch vergroten om zorgen over overprovisioning weg te nemen.
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, schaalt echter niet omlaag wanneer er geen extra capaciteit meer nodig is.
Als de toepassing capaciteit nodig heeft die het maximaal toegestane aantal TU's overschrijdt, kunt u overwegen de Premium- of 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, met uitzondering van de Premium- en Dedicated-lagen. Wanneer Event Hubs functie-apps activeert, is het mogelijk dat het aantal gelijktijdige exemplaren gelijk is aan het aantal partities.
In de hostingabonnementen Verbruik en Premium worden de exemplaren van de functie-app dynamisch geschaald om zo nodig te voldoen aan het aantal partities. Het Dedicated-hostingabonnement voert functies uit in een App Service-abonnement en vereist dat u uw exemplaren handmatig configureert of een schema voor automatisch schalen instelt. Zie Dedicated hosting plans for Azure Functions (Dedicated hostingabonnementen voor Azure Functions) voor meer informatie.
Uiteindelijk is een een-op-een-relatie tussen het aantal partities en functie-app-exemplaren het ideale doel voor maximale doorvoer in een oplossing voor stroomverwerking. Als u optimaal parallellisme wilt bereiken, moet u meerdere consumenten in een consumentengroep hebben. Voor Functions vertaalt deze doelstelling zich in veel exemplaren van een functie-app 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:
Het lijkt misschien zinvol om zoveel mogelijk partities te configureren om maximale doorvoer te bereiken en rekening te houden met de mogelijkheid van een hoger aantal gebeurtenissen. Er zijn echter verschillende belangrijke factoren om rekening mee te houden wanneer u veel partities configureert:
- Meer partities kunnen leiden tot meer doorvoer: Omdat de mate van parallelle uitvoering het aantal gebruikers (functie-app-exemplaren) is, hoe meer partities er zijn, hoe hoger de gelijktijdige doorvoer kan zijn. Dit is belangrijk wanneer u een aangewezen aantal TU's voor een Event Hub deelt met andere consumententoepassingen.
- Meer functies kunnen meer geheugen vereisen: Naarmate het aantal exemplaren van functie-apps toeneemt, neemt ook de geheugenvoetafdruk van resources in het plan toe. Op een bepaald moment kunnen te veel partities de prestaties voor gebruikers verslechteren.
- Er is een risico op tegendruk van downstreamservices: Naarmate er meer doorvoer wordt gegenereerd, loopt u het risico dat downstreamservices worden overstuurd of dat ze tegendruk krijgen. Er moet rekening worden gehouden met het uitwaaieren van consumenten bij het overwegen van de gevolgen voor de omringende bronnen. Mogelijke gevolgen zijn beperking van andere services, netwerkverzadiging en andere vormen van resourceconflicten.
- Partities kunnen schaars worden ingevuld: De combinatie van veel partities en een laag aantal gebeurtenissen kan leiden tot gegevens die verspreid zijn over partities. 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 door naar de volgende beschikbare partitie. Deze procedure biedt hoge beschikbaarheid en helpt de doorvoer voor consumenten te verhogen.
Wanneer het ordenen van een set gebeurtenissen is vereist, kan de gebeurtenisproducent opgeven dat een bepaalde partitie moet worden gebruikt voor alle gebeurtenissen van de set. De consumententoepassing die uit de partitie leest, ontvangt de gebeurtenissen in de juiste volgorde. Deze afweging biedt consistentie, maar brengt de beschikbaarheid in gevaar. Gebruik deze methode alleen als de volgorde van gebeurtenissen moet worden behouden.
Voor Functions wordt de volgorde bereikt wanneer gebeurtenissen worden gepubliceerd naar een bepaalde partitie en een door Event Hubs geactiveerde functie een lease naar dezelfde partitie verkrijgt. Op dit moment 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 te publiceren naar een specifieke partitie.
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 Door Event Hubs worden geactiveerd. Factoren zijn 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 is efficiënter omdat hiermee een deel van de overhead van functie-aanroepen wordt geëlimineerd. Tenzij u slechts één gebeurtenis hoeft te verwerken, moet uw functie worden geconfigureerd om meerdere gebeurtenissen te verwerken wanneer deze worden 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 Azure Event Hubs trigger voor Azure Functions voor meer informatie over het inschakelen van batchverwerking.
Triggerinstellingen
Verschillende configuratie-instellingen in het host.json-bestand 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 aantal, wordt de functie nog steeds aangeroepen met zoveel gebeurtenissen als er 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 opgeslagen voor de client. Het aantal prefetchs moet groter zijn dan of gelijk zijn aan de waarde maxEventBatchSize en wordt meestal ingesteld op een veelvoud van die hoeveelheid. Het instellen van deze waarde op een getal kleiner dan de instelling maxEventBatchSize kan de prestaties nadelig beïnvloeden.
- 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 een batch verwerkt. Er wordt een controlepunt gemaakt op partitieniveau voor elke lezer in de consumentengroep. Zie Event Hub triggered Azure function: Replays and Retries (blogbericht) 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 af te stemmen. De standaardwaarden zijn een redelijk uitgangspunt voor de meeste oplossingen voor gebeurtenisverwerking.
Controlepunten maken
Met controlepunten worden leesposities in een partitie-gebeurtenisreeks gemarkeerd of doorgevoerd. Het is de verantwoordelijkheid van de Functions-host naar het controlepunt wanneer gebeurtenissen worden verwerkt en aan de instelling voor de batchcontrolepuntfrequentie wordt voldaan. Zie Functies en terminologie in Azure Event Hubs voor meer informatie over controlepunten.
De volgende concepten kunnen u helpen de relatie te begrijpen 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 als geslaagd beschouwd, 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 niet van invloed zijn op het juiste gebruik van het controleren en verwerken van uitzonderingen.
- Batchfrequentie is van belang: In oplossingen voor het streamen van gebeurtenissen met grote volumes kan het handig zijn om de instelling batchCheckpointFrequency te wijzigen in een waarde die groter is dan 1. Het verhogen van deze waarde kan de snelheid van het maken van controlepunten en, als gevolg daarvan, het aantal opslag-I/O-bewerkingen verminderen.
- Herhalingen kunnen plaatsvinden: 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 opgeslagen op partitieniveau voor elke consumentengroep. Herhalingen vinden plaats wanneer een controlepunt niet optreedt tijdens de laatste aanroep van de functie en de functie opnieuw wordt aangeroepen. Zie Idempotentie voor meer informatie over duplicaten en ontdubbelingstechnieken.
Het begrijpen van controlepunten wordt essentieel wanneer u de aanbevolen procedures voor foutafhandeling en nieuwe pogingen bekijkt, 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 om de prestaties van toepassingen te bewaken. Met deze functie kunt u informatie vastleggen over functieactiviteiten, prestaties, runtime-uitzonderingen en meer. Zie Overzicht van Application Insights voor meer informatie.
Deze krachtige mogelijkheid biedt enkele belangrijke configuratieopties die van invloed zijn op de prestaties. Enkele van de opvallende 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 verslechteren met onnodige telemetrie en metrische gegevens.
- Aggregatie-instellingen configureren: Bekijk en configureer de frequentie van het aggregeren en verzenden van gegevens naar Application Insights. Deze configuratie-instelling bevindt zich in het bestand host.json , samen met vele andere opties voor steekproeven en logboekregistratie. Zie De aggregator configureren voor meer informatie.
- Schakel AzureWebJobDashboard uit: Voor apps die zijn gericht op versie 1.x van de Functions-runtime, slaat deze instelling de connection string op in een opslagaccount dat door de Azure SDK wordt gebruikt om logboeken voor het webtaakdashboard 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, wordt alle telemetrie verzonden. Het verzenden van gegevens over alle gebeurtenissen kan een nadelig effect hebben op de prestaties van de functie, met name bij scenario's voor gebeurtenisstreaming met hoge doorvoer.
Het gebruik van steekproeven en het voortdurend evalueren van de juiste hoeveelheid telemetrie die nodig is voor bewaking, is van cruciaal belang voor optimale prestaties. Telemetrie moet worden gebruikt voor algemene evaluatie van de platformstatus en voor incidentele probleemoplossing, niet om kerngegevens van het bedrijf vast te leggen. 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 onder andere:
- Resourcebeheer: De binding verwerkt zowel de levenscyclus van de client als de verbinding voor u en vermindert de kans op problemen die zich kunnen voordoen bij 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.
- Batching: 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 waarmee de gebeurtenissen worden verzonden.
We raden u ten zeerste aan de lijst met talen die door Functions worden ondersteund en de ontwikkelaarshandleidingen voor deze talen te bekijken. 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 (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 add-bewerking 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# voor het publiceren van één of meerdere gebeurtenissen.
Beperking en tegendruk
Overwegingen voor beperking zijn van toepassing op uitvoerbinding, 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 afhandelen, 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.
Functiecode
In deze sectie worden de belangrijkste gebieden behandeld waarmee rekening moet worden gehouden bij het schrijven van code voor het verwerken van gebeurtenissen in een functie die door Event Hubs wordt geactiveerd.
Asynchroon programmeren
We raden u aan uw functie te schrijven om asynchrone code te gebruiken en te voorkomen dat aanroepen worden geblokkeerd, met name wanneer het om I/O-aanroepen gaat.
Hier volgen de richtlijnen die u moet volgen wanneer u een functie schrijft om asynchroon te verwerken:
- Alle asynchrone of alle synchrone: 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 erger dan code die volledig synchroon is. Kies asynchroon of synchroon en houd de keuze helemaal bij.
- Voorkomen dat aanroepen worden geblokkeerd: Blokkerende aanroepen keren pas terug naar de beller nadat de aanroep is voltooid, in tegenstelling tot asynchrone aanroepen die onmiddellijk worden geretourneerd. Een voorbeeld in C# is het aanroepen van Task.Result of Task.Wait bij een asynchrone bewerking.
Meer informatie over het blokkeren van oproepen
Het gebruik van blokkerende aanroepen voor asynchrone bewerkingen kan leiden tot uithongering van threadpools en ertoe leiden dat het functieproces vastloopt. De crash treedt op omdat voor een blokkeringsoproep een andere thread moet worden gemaakt om te compenseren voor de oorspronkelijke aanroep 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 het controlepunt niet wordt bijgewerkt door een functiecrash. De volgende keer dat de functie wordt aangeroepen, kan deze in deze cyclus terechtkomen en lijkt deze vast te zitten of langzaam te bewegen omdat er uiteindelijk een time-out optreedt bij de uitvoering van de functie.
Het oplossen van dit fenomeen begint meestal met het controleren van de triggerinstellingen en het uitvoeren van experimenten die het aantal partities kunnen verhogen. Onderzoeken kunnen ook leiden tot het wijzigen van verschillende batchopties, zoals de maximale batchgrootte of het aantal vooraf fetchs. De indruk is dat het een doorvoerprobleem of configuratie-instelling is die alleen dienovereenkomstig moet worden afgestemd. Het kernprobleem zit 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:
- David Barkol - Nederland | Principal Solution Specialist GBB
Als u niet-openbare LinkedIn-profielen wilt zien, meldt u zich aan bij LinkedIn.
Volgende stappen
Voordat u doorgaat, kunt u overwegen deze gerelateerde artikelen te bekijken:
- Uitvoeringen bewaken in Azure Functions
- Azure Functions betrouwbare gebeurtenisverwerking
- Ontwerpen van Azure Functions voor identieke invoer
- ASP.NET Core asynchrone richtlijnen.
- Azure Event Hubs trigger voor Azure Functions