Prestaties en schaal voor Event Hubs en Azure Functions

Event Hubs
Functions

Wanneer u Azure Functions met Event Hubs, zijn er veel functies en beslissingen die van invloed zijn op zowel prestaties als schaal. Dit artikel bevat prescriptieve richtlijnen om het meeste uit deze dynamische koppeling te krijgen.

Functiegroepering

Normaal gesproken omvat een functie een werkeenheid die afzonderlijke gebeurtenissen verwerkt. Dit werk kan bestaan uit het transformeren van een gebeurtenis naar een nieuwe gegevensstructuur, of misschien een verrijkingsstap in een gegevenspijplijn voor downstreamtoepassingen.

Hoe u functies groepeert, heeft mogelijk een direct effect op de prestaties en schaalmogelijkheden van uw functie-apps. Verschillende best practices stellen groepering voor op toegangsrechten, implementatie en de gebruikspatronen die uw code aanroepen.

Andere richtlijnen voor het groeperen van functies, met overwegingen voor opslag- en consumentengroep, zijn:

  • Eén functie binnen een functie-app hosten: een geïsoleerde Event Hubs geactiveerde functie vermindert resource-verschillen tussen andere functies die worden uitgevoerd, met name functies die cpu- of geheugenintensief zijn. Dit voordeel treedt op omdat elke functie een eigen geheugen-footprint en gebruikspatronen heeft die rechtstreeks invloed kunnen hebben op de schaal van de functie-app waarin de functies worden uitgevoerd.

  • Afzonderlijke opslagaccounts voor elke functie-app: vermijd het delen van opslagaccounts tussen functie-apps. Gebruik ook niet hetzelfde opslagaccount dat wordt gebruikt voor de functie-app voor andere opslagbewerkingen of -behoeften. Het is belangrijk om afzonderlijke opslagaccounts te gebruiken omdat Event Hubs geactiveerde functies mogelijk een groot aantal opslagtransacties kunnen hebben vanwege controlepunten.

  • Een toegewezen consumentengroep maken voor elke functie-app: In een oplossing voor stroomverwerking is elke consumententoepassing gelijk aan een consumentengroep. Een functie-app is een goed voorbeeld van een consumententoepassing. Deel geen consumentengroepen tussen functie-apps en andere consumententoepassingen. Het volgende diagram bevat een voorbeeld van twee functie-apps die lezen vanuit een Event Hub, waarbij elke app een eigen specifieke consumentengroep heeft:

    Toegewezen consumentengroepen voor elke functie-app

Kortom, elke functie-app moet worden beschouwd als een afzonderlijke toepassing met een eigen, toegewezen consumentengroep. Dit zorgt voor offsetintegriteit voor elke consument en vereenvoudigt afhankelijkheden in een architectuur voor gebeurtenisstreaming. Deze configuratie biedt niet alleen elke door event hub geactiveerde functie een eigen functie-app en opslagaccount, maar helpt ook om de basis te leggen voor optimale prestaties en schaal.

Hostingplannen voor functies

Het beoordelen van de schaal van functies op verschillende abonnementen is een belangrijke stap bij het beoordelen van hostingopties.

Wanneer u het verbruiksplan gebruikt, heeft elke functie-app standaard een eigen abonnement. Functie-apps in het verbruiksplan worden onafhankelijk geschaald en zijn het meest effectief wanneer ze langlopende taken voorkomen.

De Premium en Dedicated-abonnementen worden vaak gebruikt voor het hosten van meerdere functie-apps en functies die meer CPU- en geheugenintensief zijn. Het is belangrijk te weten dat alle functie-apps in deze plannen dezelfde resources delen die aan het plan zijn toegewezen. Als functies verschillende laadprofielen of unieke vereisten hebben, kunt u deze het beste in verschillende abonnementen hosten. Dit geldt met name voor toepassingen voor stroomverwerking.

Event Hubs schalen

Als het gaat om een Event Hubs naamruimte, zijn er verschillende belangrijke instellingen die moeten worden geëvalueerd om piekprestaties en schaal te garanderen. Deze sectie richt zich op de Standard-laag van Event Hubs en de unieke functies die van invloed zijn op schalen wanneer deze worden gebruikt met Azure Functions. Zie Basic versus Standard vs. premium versus dedicated tiers voor meer informatie over Event Hubs-lagen.

Inzicht in doorvoereenheden

In de Event Hubs standard-laag wordt doorvoer geclassificeerd als de hoeveelheid gegevens die binnen een bepaalde periode worden binnengekomen en gelezen uit de naamruimte. Een doorvoereenheid (TU) is een mechanisme dat wordt gebruikt om te meten en beheren hoeveel doorvoer een Event Hubs naamruimte ondersteunt.

Ter referentie kan een naamruimte in Event Hubs worden vergeleken met een cluster in Kafka. Voor een conceptuele toewijzing tussen Kafka en Event Hubs, bekijkt u deze tabel.

Elke doorvoereenheid wordt per uur gefactureerd en wordt gedeeld met alle Event Hubs in een naamruimte. Dit betekent dat alle toepassingen en services, zowel uitgevers als consumenten, moeten worden meegenomen bij het kiezen van het aantal toegewezen TUs. Azure Functions heeft invloed op het aantal bytes en gebeurtenissen dat zowel naar als uit een Event Hub wordt gelezen.

De nadruk voor het bepalen van het aantal TUS's ligt rond het punt van ingress. De aggregatie voor de consumententoepassingen, met inbegrip van de snelheid waarmee deze gebeurtenissen worden verwerkt, moet echter ook worden opgenomen in de berekening.

Omhoog schalen met automatisch opschalen

Automatisch vergroot kan worden ingeschakeld op een Event Hubs om scenario's mogelijk te maken waarin de belasting toeneemt boven het geconfigureerde aantal TUs. Dit zorgt ervoor dat de beperking van de service niet optreedt en dat de verwerking, inclusief het opnemen van gebeurtenissen, zonder onderbreking kan worden voortgezet. Aangezien DE's een van de belangrijke instellingen zijn die ook van invloed zijn op de kosten, helpt het gebruik van de functie voor automatisch inbouwen om problemen met overprovisioning te voorkomen.

Automatisch opschalen is een unieke functie van Event Hubs die vaak wordt verward met automatisch schalen, met name in de context van serverloze oplossingen. Het is belangrijk te weten dat dit kenmerk in Event Hubs het dynamisch verhogen van TUS's ondersteunt ter ondersteuning van bursts-scenario's, maar geen functie heeft om automatisch af te schalen of af te schalen.

Voor scenario's waarvoor een hoge doorvoer is vereist en die niet kunnen worden aangepast met het maximaal toegewezen aantal TUs, kunt u de Azure Event Hubs Premium-laag of toegewezen cluster overwegen.

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 u de Event Hubs trigger gebruikt, kan het aantal gelijktijdige functie-app-exemplaren overeenkomen met het aantal partities.

In Verbruiks- Premium-abonnementen worden de exemplaren van de functie-app dynamisch geschaald om te voldoen aan het aantal partities, indien nodig. Voor toegewezen (App Service) abonnementen moet u uw exemplaren handmatig configureren of een schema voor automatisch schalen instellen. 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.

Optimale parallellisme wordt bereikt door meerdere consumenten binnen een consumentengroep te hebben. Voor Azure Functions wordt dit omgezet in veel exemplaren van een functie-app binnen het plan. Het resultaat wordt aangeduid als parallellisme op partitieniveau of de maximale mate van parallellisme.

Maximale mate van parallellisme

Het kan in eerste instantie zinvol zijn om zoveel mogelijk partities te configureren om een maximale doorvoer te bereiken en rekening te houden met de mogelijkheid van een groter aantal gebeurtenissen. Er zijn echter enkele belangrijke factoren die in aanmerking moeten worden genomen wanneer veel partities zijn geconfigureerd:

  • Meer partities kunnen leiden tot meer doorvoer: Omdat de mate van parallellisme het aantal consumenten (functie-app-exemplaren) is, hoe meer partities er zijn, hoe hoger de gelijktijdige doorvoer kan zijn. Dit is belangrijk wanneer u een aangewezen aantal TUs voor een Event Hub deelt met andere consumententoepassingen.

  • Voor meer functies is mogelijk meer geheugen vereist: Naarmate het aantal instanties van de functie-app toeneemt, neemt ook de geheugenvoetafdruk van resources binnen het plan toe. Op een bepaald moment kunnen te veel partities de prestaties voor consumenten verslechteren.

  • Back-druk van downstreamservices: Naarmate er meer doorvoer wordt gegenereerd, kan de kans ontstaan dat de druk van downstreamservices wordt overbelast of teruggenomen. Bij het overwegen van de gevolgen voor de omliggende resources moet rekening worden gehouden met het fan-outgedrag van consumenten. Voorbeelden hiervan zijn beperking van andere services, netwerkverzadiging en andere vormen van bronbezetting die kunnen optreden met een toename van de doorvoer.

  • Sparsely populated partitions: De combinatie van veel partities en een laag volume aan gebeurtenissen kan leiden tot gegevens die niet worden verdeeld over partities. In plaats daarvan kan een kleiner aantal partities optimale prestaties en resourcegebruik bieden die Functions kan gebruiken.

Beschikbaarheid en consistentie

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

Wanneer ordenen belangrijk is, kan een specifieke partitie worden opgegeven om de volgorde van gebeurtenissen te behouden wanneer ze worden gepubliceerd. Een consumententoepassing die uit dezelfde partitie leest, kan de gebeurtenissen vervolgens op volgorde verwerken. Dit compromis biedt consistentie, maar brengt de beschikbaarheid in gevaar. Gebruik de methode alleen wanneer het orden van gebeurtenissen een vereiste is.

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

Voor een gedetailleerdere uitleg van de manier waarop beschikbaarheid en consistentie worden ondersteund door Azure Event Hubs, is het raadzaam dit artikel te lezen.

Event Hubs trigger

Deze sectie richt zich op de instellingen en overwegingen die betrokken zijn bij het optimaliseren Event Hubs geactiveerde functies voor piekprestaties. Factoren zijn batchverwerking, sampling en gerelateerde functies die van invloed zijn op het gedrag van een Event Hub-triggerbinding.

Batchverwerking

Functies die worden geactiveerd door Event Hubs, kunnen worden geconfigureerd voor het verwerken van een verzameling gebeurtenissen of één gebeurtenis tegelijk. Het verwerken van een batch gebeurtenissen is efficiënter vanwege de overhead die bij elke functie-aanroep komt kijken. Tenzij u slechts één gebeurtenis hoeft te verwerken, moet uw functie worden geconfigureerd voor het verwerken van meerdere gebeurtenissen wanneer deze wordt aangeroepen.

Het inschakelen van batching voor Event Hubs triggerbinding varieert per taal:

  • In C# wordt kardinaliteit automatisch geconfigureerd wanneer een matrix wordt aangewezen voor het type in het EventHubTrigger kenmerk .

  • JavaScript, Python en andere talen maken batching mogelijk wanneer de eigenschap kardinaliteit is ingesteld op veel in het bestand function.json voor de functie.

Zie het kenmerk en de aantekeningopties voor elke ondersteunde taal voor meer informatie over hoe batching is ingeschakeld.

Triggerinstellingen

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

  • maxBatchSize: Deze instelling vertegenwoordigt het maximum aantal gebeurtenissen dat de functie ontvangt wanneer deze wordt aangeroepen. Het is belangrijk te weten dat dit niet het minimale aantal gebeurtenissen is, maar alleen het maximum. Als het aantal ontvangen gebeurtenissen kleiner is dan dit aantal, wordt de functie nog steeds aangeroepen met zoveel gebeurtenissen als beschikbaar zijn. U kunt de minimale batchgrootte niet instellen.

  • prefetchCount: Een van de belangrijkste instellingen bij het optimaliseren voor prestaties is het aantal vooraf opgetelde resultaten. Naar deze waarde wordt verwezen door het onderliggende AMQP-kanaal om te bepalen hoeveel berichten er voor de client moeten worden opgehaald en in de cache moeten worden opgeslagen. Het aantal prefetch moet groter zijn dan of gelijk zijn aan de waarde en wordt meestal maxBatchSize ingesteld op een veelvoud van die hoeveelheid. Als u deze waarde instelt op een getal dat lager is maxBatchSize dan de instelling, kan dit een negatieve invloed hebben op de prestaties.

  • batchCheckpointFrequency: Wanneer batches door uw functie worden verwerkt, wordt deze waarde gebruikt om de snelheid te bepalen waarmee een controlepunt wordt gemaakt. Deze waarde is standaard ingesteld op , wat betekent dat er een controlepunt wordt gemaakt nadat een functie een 1 batch heeft verwerkt. Houd er rekening mee dat er een controlepunt wordt gemaakt op partitieniveau voor elke lezer in de consumentengroep. Dit interessante blogbericht biedt meer inzicht in het gedrag dat deze instelling kan introduceren en hoe deze van invloed is op herhalingen en nieuwe gebeurtenissen.

De waarden die u voor de triggerbinding in stelt, moeten worden bepaald in de loop van verschillende prestatietests en iteraties. Het wordt aanbevolen om wijzigingen iteratief te maken en consistent te meten om deze opties dienovereenkomstig af te stemmen. De standaardwaarden zijn een poging om een beginpunt te bieden voor de meeste oplossingen voor gebeurtenisverwerking.

Controlepunten maken

Inzicht in het concept van controlepunten is essentieel voor Event Hubs geactiveerde functies. Het is de verantwoordelijkheid van de Functions-host om controlepunten te maken wanneer gebeurtenissen worden verwerkt en aan de instelling voor de frequentie van het batchcontrolepunt wordt voldaan.

De volgende concepten zijn belangrijk om inzicht te krijgen in de relatie tussen controlepunten en hoe uw functie gebeurtenissen verwerkt:

  • Uitzonderingen tellen nog steeds mee voor succes: Als het functieproces niet vast loopt tijdens het verwerken van gebeurtenissen, wordt de voltooiing van de functie als geslaagd beschouwd. Het afhandelen van uitzonderingen moet nog steeds een verdedigingsbenadering zijn in de functiecode. Als dit lukt, evalueert de Functions-host de instelling voor het controlepunt voor de batchfrequentie en maakt deze een controlepunt als dit is bereikt, ongeacht de uitzonderingen die tijdens de verwerking zijn opgetreden.

  • Batchfrequentie is van belang: Bij oplossingen voor het streamen van gebeurtenissen met een hoog volume kan het nuttig zijn om de instelling batchCheckpointFrequency te wijzigen in een waarde die groter is dan 1. Door deze waarde te verhogen, kunt u de snelheid verminderen waarmee een controlepunt wordt gemaakt, waardoor het aantal I/O-bewerkingen naar het opslagaccount wordt verminderd en betere prestaties worden bereikt.

  • Er kunnen herhalingen 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. Er is benadrukt dat de offset voor elke consument wordt opgeslagen op het partitieniveau voor elke consumentengroep. Herhalingen vinden plaats wanneer er geen controlepunt is uitgevoerd tijdens de laatste aanroep van de functie en deze opnieuw wordt aangeroepen. Zie Idempotentie in het volgende artikel voor meer informatie over duplicaten en ontdubbelingstechnieken.

Inzicht in controlepunten wordt essentieel bij het overwegen van best practices voor foutafhandeling en nieuwe fouten, die in een latere sectie van dit artikel worden behandeld.

Telemetriesteekproeven

Azure Functions biedt ingebouwde ondersteuning voor Application Insights. Met deze functie kunt u logboekgegevens, prestaties en informatie verzamelen over runtime-uitzonderingen die binnen uw functies optreden. Deze krachtige installatie biedt enkele belangrijke configuratieopties die van invloed zijn op de prestaties. Enkele van de belangrijkste instellingen en overwegingen voor bewaking en prestaties zijn:

  • Schakel telemetriesampling in: voor scenario's met hoge doorvoer moet u de hoeveelheid telemetrie en informatie evalueren die u nodig hebt. Bekijk de functie voor het nemen van telemetriesampling in Application Insights om te voorkomen dat de prestaties van uw functie worden gedegraded met onnodige telemetriegegevens en metrische gegevens.

  • Aggregatie-instellingen configureren: Bekijk en configureer de frequentie waarin gegevens worden geaggregeerd en verzonden naar Application Insights. Deze configuratie-instelling staat in het bestand host.json, samen met veel andere opties voor steekproeven en logboekregistratie. Zie De aggregator configureren voor meer informatie.

  • AzureWebJobDashboard uitschakelen: voor apps die gericht zijn op versie 1.x van de Azure Functions-runtime, slaat deze instelling de connection string op in een opslagaccount dat wordt gebruikt door de Azure SDK om logboeken voor het WebJobs-dashboard te bewaren. Als Application Insights wordt gebruikt in plaats van het WebJobs-dashboard, moet deze instelling worden verwijderd. Zie de naslag voor AzureWebJobsDashboard-instellingen voor meer informatie.

Het is belangrijk om te vermelden dat wanneer Application Insights is ingeschakeld zonder steekproeven, alle telemetriegegevens worden verzonden. Het verzenden van gegevens over alle gebeurtenissen kan een nadelig effect hebben op de algehele prestaties van de functie, met name bij scenario's voor het streamen van gebeurtenissen met hoge doorvoer.

Het gebruik van steekproeven en het voortdurend beoordelen van de juiste hoeveelheid telemetrie die nodig is voor bewaking is een van de vele, cruciale instellingen die beschikbaar zijn voor optimale prestaties. Telemetrie moet worden gebruikt voor algemene evaluatie van de platformtoestand in de aggregatie en voor incidentele probleemoplossing, en niet voor het vastleggen van belangrijke zakelijke metrische gegevens. Zie Sampling configureren voor meer informatie.

Uitvoerbinding

Publiceren naar een gebeurtenisstroom vanuit een functie wordt vereenvoudigd met behulp van de uitvoerbinding voor Event Hubs. Enkele voordelen van het gebruik van deze binding zijn:

  • Resourcebeheer: de binding verwerkt zowel de client- als de verbindingslevenscyclus voor u. Dit vermindert de kans op problemen die zich kunnen voordoen met uitputting van de poort en het beheer van verbindingspools.

  • Minder code: De binding abstract maakt de onderliggende SDK abstract en vermindert de hoeveelheid code die nodig is om gebeurtenissen te publiceren. Dit resulteert in code die eenvoudiger te schrijven en te onderhouden is.

  • Batching: voor verschillende talen wordt batching ondersteund om efficiënt te publiceren naar een gebeurtenisstroom. Dit kan de prestaties verbeteren en helpen code te stroomlijnen die de gebeurtenissen verzendt.

Het wordt ten zeerste aanbevolen om de lijst met ondersteunde talen voor Azure Functions en hun respectieve handleidingen voor ontwikkelaars te bekijken. De sectie Bindingen voor elke taal bevat gedetailleerde voorbeelden en documentatie.

Batchverwerking

Als uw functie slechts één gebeurtenis publiceert, is het configureren van de binding met een retourwaarde een algemene benadering. Dit is handig als de uitvoering van de functie altijd eindigt met een instructie die de gebeurtenis verzendt. Het gebruik van de retourwaarde is een patroon dat alleen mag worden gebruikt voor synchrone functies die slechts één gebeurtenis retourneren.

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

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

Meerdere gebeurtenissen in C uitvoer

Gebruik de ICollector typen en bij het verzenden van meerdere gebeurtenissen vanuit een functie in IAsyncCollector C#.

  • De ICollector<T>.Add() methode kan worden gebruikt in zowel synchrone als asynchrone functies. De add-bewerking wordt uitgevoerd zodra deze wordt aangeroepen.

  • de IAsyncCollector<T>.AddAsync() methode bereidt de gebeurtenissen voor die moeten worden gepubliceerd naar de gebeurtenisstroom. Als u een asynchrone functie schrijft, moet u gebruiken om IAsyncCollector de gepubliceerde gebeurtenissen beter te beheren.

Raadpleeg de documentatie voor voorbeelden van het publiceren van zowel één als meerdere gebeurtenissen met behulp van C#.

Bandbreedtebeperking en back-druk

Beperkingsoverwegingen zijn ook van toepassing op uitvoerbinding, niet alleen voor Event Hubs maar ook voor Azure-services zoals Azure Cosmos DB. Over het algemeen is het 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 uitzonderingen van IAsyncCollector afvangen door AddAsync en FlushAsync te verpakken in een uitzonderings-handler voor .NET Azure Functions of door uitvoerbindingen niet te gebruiken en de Event Hubs-SDK's rechtstreeks te gebruiken.

Functiecode

Deze sectie bevat de belangrijkste gebieden die moeten worden overwogen bij het schrijven van code voor het verwerken van gebeurtenissen van Event Hubs geactiveerde functie.

Asynchroon programmeren

Het is raadzaam om uw functie niet-blokkerende, asynchrone code te laten gebruiken. Dit is belangrijk wanneer er I/O-aanroepen bij betrokken zijn.

Wanneer u asynchrone programmering in een Functions overweegt, zijn er enkele essentiële richtlijnen die moeten worden gevolgd:

  • Alle asynchroon of alle synchroon: Als een functie zo is geconfigureerd dat deze asynchroon wordt uitgevoerd, moeten alle I/O-aanroepen ook asynchroon zijn. In de meeste gevallen kan gedeeltelijk asynchroon zijn slechter dan code die volledig synchroon is. Kies asynchroon of synchroon voor de implementatie van de functie en volg deze helemaal door.

  • Blokkering van aanroepen voorkomen: Blokkerende oproepen worden pas terug naar de aanroeper nadat de aanroep is voltooid. Dit is anders dan asynchrone aanroepen die onmiddellijk worden retourneren. Een voorbeeld in C# is het aanroepen van Task.Result of Task.Wait op een asynchrone bewerking.

Meer informatie over het blokkeren van aanroepen

Wanneer blokkerende aanroepen worden uitgevoerd op asynchrone bewerkingen, kan dit leiden tot het uitsterken van threadpools en kan het functieproces vastlopers veroorzaken. Dit gebeurt omdat voor een blokkerende aanroep een andere thread moet worden gemaakt om te compenseren voor de oorspronkelijke aanroep die nu wacht. Als gevolg hiervan zijn er nu twee keer zoveel threads nodig om de bewerking te voltooien.

Het vermijden van deze synchronisatie via asynchrone benadering is met name belangrijk wanneer Event Hubs betrokken is, omdat het controlepunt niet wordt bijgewerkt door een crash naar de functie. De volgende keer dat de functie wordt aangeroepen, kan deze in deze cyclus eindigen en lijken te zijn vastgelopen of langzaam te worden verplaatst, omdat er uiteindelijk een time-out voor functie-uitvoeringen is.

Het oplossen van dit verschijnsel begint meestal met het controleren van de triggerinstellingen en het uitvoeren van experimenten waarbij het aantal partities kan toenemen. 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 belangrijkste probleem zit echter in de code zelf en moet daar worden opgelost voor de juiste oplossing.

Volgende stappen

Voordat u doorgaat, kunt u deze gerelateerde artikelen lezen:

Resilient Event Hubs en Functions-ontwerp