Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
Questo articolo fornisce indicazioni per ottimizzare la scalabilità e le prestazioni quando si usano Hub eventi di Azure e Funzioni di Azure insieme nelle applicazioni.
Raggruppamento di funzioni
In genere, una funzione incapsula un'unità di lavoro in un flusso di elaborazione eventi. Ad esempio, una funzione può trasformare un evento in una nuova struttura di dati o arricchire i dati per le applicazioni downstream.
In Funzioni di Azure un'app per le funzioni fornisce il contesto di esecuzione per le funzioni. I comportamenti dell'app per le funzioni si applicano a tutte le funzioni ospitate dall'app per le funzioni. Le funzioni in un'app per le funzioni vengono distribuite insieme e ridimensionate insieme. Tutte le funzioni in un'app per le funzioni devono condividere lo stesso linguaggio.
Il modo in cui si raggruppano le funzioni nelle app per le funzioni può influire sulle funzionalità di prestazioni e ridimensionamento delle app per le funzioni. È possibile raggruppare le funzioni in base ai diritti di accesso, alla distribuzione e ai modelli di utilizzo che richiamano il codice.
Per indicazioni su Funzioni di Azure procedure consigliate per il raggruppamento e altri elementi di progettazione, vedere Procedure consigliate per Funzioni di Azure affidabili e Migliorare le prestazioni e l'affidabilità delle Funzioni di Azure.
L'elenco seguente fornisce indicazioni per il raggruppamento delle funzioni. Le linee guida includono considerazioni sull'archiviazione e sui gruppi di consumer.
Ospitare una singola funzione in un'app per le funzioni: Se Hub eventi attiva una funzione, è possibile isolare tale funzione nella propria app per le funzioni per ridurre i conflitti con altre funzioni. L'isolamento è particolarmente importante se le altre funzioni sono a elevato utilizzo di CPU o memoria. Questa tecnica è utile perché ogni funzione ha un proprio footprint di memoria e modelli di utilizzo che possono influire direttamente sul ridimensionamento dell'app per le funzioni che lo ospita.
Assegnare a ogni app per le funzioni il proprio account di archiviazione: evitare di condividere gli account di archiviazione tra le app per le funzioni. Inoltre, se un'app per le funzioni usa un account di archiviazione, non usare tale account per altre operazioni di archiviazione o esigenze. Può essere particolarmente importante evitare di condividere gli account di archiviazione per le funzioni attivate dagli Event Hubs, poiché tali funzioni possono avere un elevato volume di transazioni di archiviazione a causa del processo di checkpoint.
Creare un gruppo di consumatori dedicato per ogni app di funzioni: un gruppo di consumatori è una visualizzazione di un hub di eventi. I diversi gruppi di consumatori hanno punti di vista diversi, il che significa che gli stati, le posizioni e gli offset possono differire. I gruppi di consumatori consentono a più applicazioni di avere proprie visualizzazioni del flusso di eventi e di leggere il flusso in modo indipendente al proprio ritmo e con i propri offset. Per altre informazioni sui gruppi di consumer, vedere Funzionalità e terminologia in Hub eventi di Azure.
Un gruppo di consumer è associato a una o più applicazioni consumer e un'applicazione consumer può usare uno o più gruppi di consumer. In una soluzione di elaborazione dei flussi, ciascuna applicazione cliente corrisponde a un gruppo di consumatori. Un'app per le funzioni è un esempio principale di un'applicazione consumer. Il diagramma seguente mostra un esempio di due app per funzioni che leggono da un hub di eventi. Ogni app ha un proprio gruppo di consumer dedicato.
Il flusso nel diagramma inizia con i produttori di eventi. Tre etichette di protocollo, HTTPS, AMQP e Kafka, appaiono a destra dei producer, che indicano i protocolli di ingresso supportati. Una singola freccia parte dai produttori, passando attraverso questi protocolli, verso il componente centrale, un grande riquadro con l'etichetta Hub eventi di Azure. All'interno della casella Hub eventi di Azure sono presenti quattro partizioni. A destra della casella Hub eventi di Azure sono presenti due gruppi di consumer disposti verticalmente. Alla destra dei gruppi di utenti ci sono otto app funzione. Le frecce a tinta unita puntano dalle prime quattro app al gruppo di consumer 1 e quindi a tutte e quattro le partizioni. Le frecce tratteggiate puntano dalle ultime quattro app al gruppo di consumer 2 e quindi a tutte e quattro le partizioni.
Non condividere gruppi di consumatori tra applicazioni di funzione e altre applicazioni consumer. Fare in modo che ogni app per funzioni sia un'applicazione distinta con un proprio gruppo di consumer dedicato, per garantire l'integrità degli offset per ogni consumer e semplificare le dipendenze in un'architettura di streaming di eventi. Questa configurazione, oltre a fornire a ogni funzione attivata dall'hub eventi la propria app per le funzioni e l'account di archiviazione, consente di impostare le basi per ottenere prestazioni e scalabilità ottimali.
Piani di hosting delle funzioni
Le app per le funzioni offrono diverse opzioni di hosting. Esaminare le funzionalità per scegliere l'opzione migliore. Per altre informazioni, vedere Funzioni di Azure opzioni di hosting. Prestare attenzione alla scalabilità di ogni opzione.
Il piano Flex Consumption è il piano di hosting serverless consigliato per Funzioni di Azure, inclusi i carichi di lavoro basati su eventi attivati da Hub eventi. Esegue il ridimensionamento di ogni funzione attivata da Event Hubs su istanze dedicate usando regole di ridimensionamento in base alla destinazione per Event Hubs.
I piani Premium e Dedicato vengono spesso usati per ospitare più app per le funzioni e funzioni che richiedono un utilizzo maggiore di CPU e memoria. Con il piano dedicato Servizio app di Azure, si eseguono le funzioni in un piano servizio app di Azure a tariffe regolari del piano servizio app. Tutte le app per le funzioni in questi piani condividono le risorse allocate al piano. Se le funzioni hanno profili di carico o requisiti univoci diversi, è consigliabile ospitarli in piani diversi, soprattutto nelle applicazioni di elaborazione dei flussi.
App Azure Container offre supporto integrato per lo sviluppo, la distribuzione e la gestione di app per le funzioni in contenitori in Funzioni di Azure. Grazie a questo supporto, è possibile usare App contenitore per eseguire le funzioni guidate dagli eventi in un ambiente completamente gestito e basato su Kubernetes con supporto predefinito per il monitoraggio open source, mTLS, Dapr e KEDA.
Ridimensionamento di Event Hubs
Quando si distribuisce uno spazio dei nomi di Hub eventi, è necessario impostare correttamente diverse impostazioni importanti per garantire prestazioni e scalabilità ottimali. Questa sezione è incentrata sul livello Standard di Hub eventi e sulle funzionalità univoche di tale livello che influiscono sul ridimensionamento quando si usano anche Funzioni di Azure. Per altre informazioni sui livelli di Hub eventi, vedere Livelli Basic e Standard rispetto a Premium e Dedicati.
Uno spazio dei nomi di un Hub eventi corrisponde a un cluster Kafka. Per informazioni sulla correlazione tra Hub eventi e Kafka, vedere Che cos'è Hub eventi di Azure per Apache Kafka?.
Informazioni sulle unità di throughput (TU)
Nel livello Standard di Hub eventi la velocità effettiva viene classificata come quantità di dati immessi e letti dallo spazio dei nomi per unità di tempo. Le TUs sono unità di capacità di throughput pre-acquistate.
Le UR vengono fatturate su base oraria.
Tutti gli hub eventi in un'area dei nomi condividono le UT. Per calcolare correttamente le esigenze di capacità, è necessario considerare tutte le applicazioni e i servizi, sia gli editori che i consumer. Le funzioni influiscono sul numero di byte ed eventi pubblicati in e letti da un hub di eventi.
L'enfasi per determinare il numero di TUs è sul punto di ingresso. Tuttavia, l'aggregazione per le applicazioni consumer, inclusa la frequenza di elaborazione di tali eventi, deve essere inclusa anche nel calcolo.
Per altre informazioni sulle unità di throughput di Hub eventi, vedere Unità di throughput.
Scala con inflazione automatica
È possibile abilitare Auto-inflate per uno spazio dei nomi di Hub eventi per gestire situazioni in cui il carico supera il numero configurato di TUs. L'uso di Auto-inflate evita la limitazione dell'applicazione e contribuisce a garantire che l'elaborazione, inclusa l'acquisizione di eventi, continui senza interruzioni. Poiché l'impostazione del TU influisce sui costi, l'uso dell'espansione automatica aiuta a mitigare le preoccupazioni di sovraprovisionamento.
Auto-inflate è una funzionalità di *Event Hubs* spesso confusa con l'autoscalabilità, soprattutto nel contesto delle soluzioni serverless. Tuttavia, l'aumento automatico, a differenza della scalabilità automatica, non riduce la capacità quando quella aggiuntiva non è più necessaria.
Se l'applicazione necessita di capacità che superi il numero massimo consentito di TUs, prendere in considerazione l'uso di Event Hubs del livello Premium o del livello Dedicato.
Partizioni e funzioni simultanee
Quando si crea un hub eventi, è necessario specificare il numero di partizioni. Il numero di partizioni rimane fisso e non può essere modificato ad eccezione dei livelli Premium e Dedicato. Quando Hub eventi attiva le app per le funzioni, il numero di istanze simultanee può essere uguale al numero di partizioni.
Nei piani di hosting a consumo e Premium, le istanze dell'app per le funzioni aumentano in modo dinamico per soddisfare il numero di partizioni, se necessario. Il piano di hosting dedicato esegue funzioni in un piano di servizio app e richiede di configurare manualmente le istanze o configurare uno schema di scalabilità automatica. Per altre informazioni, vedere Piani di hosting dedicati per Funzioni di Azure.
Una corrispondenza biunivoca tra il numero di partizioni e il numero di istanze di funzione, o consumer, è l'obiettivo ideale per ottenere la massima velocità di elaborazione in una soluzione di elaborazione di flussi. Per ottenere un parallelismo ottimale, utilizzare più consumer all'interno di un gruppo di consumer. Per Funzioni di Azure, questo obiettivo si traduce in molte istanze di una funzione nel piano. Il risultato viene definito parallelismo a livello di partizione o il grado massimo di parallelismo, come illustrato nel diagramma seguente.
Il diagramma è suddiviso in due sezioni denominate: un flusso partizionato e un gruppo di consumer. Nel flusso vengono visualizzate cinque partizioni. Ogni partizione contiene barre verticali che rappresentano singoli eventi nel flusso. Cinque gruppi di consumer appaiono a destra delle partizioni, uno per ogni partizione. Sul lato destro, l'etichetta «grado massimo di parallelismo» indica che una corrispondenza uno a uno tra partizioni e istanze rappresenti il livello massimo di parallelismo.
Potrebbe sembrare opportuno configurare il maggior numero possibile di partizioni per ottenere la velocità effettiva massima e tenere conto della possibilità di un volume maggiore di eventi. Esistono tuttavia diversi fattori importanti da considerare quando si configurano molte partizioni:
Più partizioni possono portare a una maggiore velocità effettiva: poiché il grado di parallelismo è il numero di consumer (istanze di funzione), maggiore è il numero di partizioni presenti, maggiore è la velocità effettiva simultanea. Questa considerazione è importante quando si condivide un numero specifico di TU per un hub di eventi con altre applicazioni consumer.
Altre funzioni possono richiedere più memoria: man mano che aumenta il numero di istanze di funzione, aumenta anche il footprint della memoria delle risorse nel piano. A un certo punto, troppe partizioni possono peggiorare le prestazioni per i consumatori.
C'è un rischio di back pressure dai servizi downstream: man mano che viene generata una maggiore velocità effettiva, si rischia di sovraccaricare i servizi downstream o di ricevere una contropressione da tali servizi. Tenere conto del fan-out dei consumatori quando si valutano le conseguenze sulle risorse circostanti. Le possibili conseguenze includono la limitazione della velocità imposta da altri servizi, la saturazione della rete e altre forme di contesa delle risorse.
Le partizioni possono essere popolate in modo sparse: la combinazione di molte partizioni e un volume ridotto di eventi può portare a dati distribuiti in modo sparse tra le partizioni. Al contrario, un numero minore di partizioni può offrire prestazioni migliori e un utilizzo delle risorse.
Disponibilità e coerenza
Quando non si specifica una chiave di partizione o un ID, Hub eventi instrada un evento in ingresso alla partizione disponibile successiva. Questo design offre alta disponibilità e contribuisce ad aumentare il throughput per i consumatori.
Quando è necessario ordinare un set di eventi, il producer di eventi può specificare che una determinata partizione deve essere utilizzata per tutti gli eventi del set. L'applicazione consumer che legge dalla partizione riceve gli eventi nell'ordine corretto. Questo compromesso garantisce coerenza, ma compromette la disponibilità. Non usare questo approccio a meno che non sia necessario mantenere l'ordine degli eventi.
In Funzioni di Azure, l'ordinamento viene ottenuto quando gli eventi vengono pubblicati in una determinata partizione e una funzione attivata da Event Hubs acquisisce un lease sulla stessa partizione. Attualmente la possibilità di configurare una partizione con il binding di output di Event Hubs non è supportata. Usare invece uno degli SDK di Hub eventi per pubblicare in una partizione specifica.
Per altre informazioni su come Hub eventi supporta la disponibilità e la coerenza, vedere Disponibilità e coerenza in Hub eventi.
Trigger per hub di eventi
Questa sezione è incentrata sulle impostazioni e sulle considerazioni per l'ottimizzazione delle funzioni attivate da Hub eventi. I fattori includono l'elaborazione batch, il campionamento e le funzionalità correlate che influenzano il comportamento di un'associazione di trigger dell'hub eventi.
Invio in batch per le funzioni attivate
È possibile configurare le funzioni attivate da un hub eventi per elaborare un batch di eventi o un evento alla volta. L'elaborazione di un batch di eventi può essere più efficiente quando riduce il sovraccarico delle chiamate di funzione. A meno che non sia necessario elaborare solo un singolo evento, configurare la funzione per elaborare più eventi quando viene richiamato.
L'abilitazione dell'elaborazione in batch per il binding trigger di Event Hubs varia a seconda del linguaggio:
JavaScript, Python e altri linguaggi consentono l'invio in batch quando la proprietà di cardinalità è impostata su molti nel file function.json per la funzione.
In C# la cardinalità viene configurata automaticamente quando viene designata una matrice per il tipo nell'attributo EventHubTrigger .
Per ulteriori informazioni su come è abilitata l'aggregazione, vedere Hub eventi di Azure trigger per Funzioni di Azure.
Impostazioni di attivazione
Diverse impostazioni di configurazione nel file host.json svolgono un ruolo chiave nelle caratteristiche delle prestazioni dell'associazione di trigger di Hub eventi per Funzioni:
maxEventBatchSize: questa impostazione rappresenta il numero massimo di eventi che la funzione può ricevere quando viene richiamata. Se il numero di eventi ricevuti è minore di questo importo, la funzione viene comunque richiamata con il numero di eventi disponibili. Non è possibile impostare una dimensione minima del batch.
prefetchCount: il conteggio di prelettura è una delle impostazioni più importanti quando si ottimizzano le prestazioni. Il canale AMQP sottostante fa riferimento a questo valore per determinare il numero di messaggi da recuperare e memorizzare nella cache per il client. Il numero di prelettura deve essere maggiore o uguale a maxEventBatchSize ed è comunemente impostato su un multiplo di quel valore. L'impostazione di questo valore su un numero minore dell'impostazione maxEventBatchSize può compromettere le prestazioni.
batchCheckpointFrequency: Quando la funzione elabora i batch, questo valore determina la frequenza con cui vengono creati i checkpoint. Il valore predefinito è 1, il che significa che è presente un checkpoint ogni volta che una funzione elabora correttamente un singolo batch. Viene creato un checkpoint a livello di partizione per ogni lettore nel gruppo di consumatori. Per informazioni su come questa impostazione influisce sulle riesecuzioni e i tentativi di eventi, vedere Funzione di Azure attivata dall'hub eventi: Riesecuzioni e tentativi (post di blog).
Eseguite diversi test di prestazioni per determinare i valori da impostare per il binding del trigger. È consigliabile modificare le impostazioni in modo incrementale e misurare in modo coerente per ottimizzare queste opzioni. I valori predefiniti sono un punto di partenza ragionevole per la maggior parte delle soluzioni di elaborazione degli eventi.
Checkpoint
Checkpoint contrassegnano o confermano le posizioni del lettore in una sequenza di eventi di una partizione. È responsabilità dell'host di Functions eseguire il checkpoint durante l'elaborazione degli eventi e quando viene soddisfatta l'impostazione della frequenza dei checkpoint in batch. Per ulteriori informazioni sul checkpointing, vedere Caratteristiche e terminologia in Hub eventi di Azure.
I concetti seguenti consentono di comprendere la relazione tra il checkpoint e il modo in cui la funzione elabora gli eventi:
Le eccezioni continuano a essere considerate riuscite: se il processo della funzione non si arresta in modo anomalo durante l'elaborazione degli eventi, il completamento della funzione viene considerato riuscito, anche se si sono verificate eccezioni. Al termine della funzione, l'host di Funzioni valuta batchCheckpointFrequency. Se è il momento di un checkpoint, ne crea uno, indipendentemente dal fatto che ci siano eccezioni. Il fatto che le eccezioni non influiscano sul processo di checkpoint non dovrebbe influire sull'uso corretto del controllo e della gestione delle eccezioni.
La frequenza batch è importante: Nelle soluzioni di streaming di eventi con volume elevato, può essere utile modificare l'impostazione batchCheckpointFrequency su un valore maggiore di 1. L'aumento di questo valore può ridurre la frequenza di creazione del checkpoint e, di conseguenza, il numero di operazioni di I/O di memorizzazione.
Le riesecuzioni possono verificarsi: Ogni volta che una funzione viene invocata con il binding del trigger di Event Hubs, viene usato il checkpoint più recente per determinare da dove riprendere l'elaborazione. L'offset per ogni consumer è salvato a livello di partizione per ogni gruppo di consumatori. Le riesecuzioni si verificano quando non viene eseguito alcun checkpoint durante l'ultima invocazione della funzione e la funzione viene invocata nuovamente. Per ulteriori informazioni sui duplicati e sulle tecniche di deduplicazione, vedere Idempotency.
La comprensione della creazione di checkpoint diventa fondamentale nel considerare le migliori pratiche per la gestione degli errori e i tentativi; questo argomento verrà trattato più avanti in questo articolo.
Campionamento dei dati di telemetria
Funzioni offre il supporto predefinito per Application Insights, un'estensione di Monitoraggio di Azure che offre funzionalità di monitoraggio delle prestazioni delle applicazioni. Con questa funzionalità è possibile registrare informazioni sulle attività di funzione, sulle prestazioni, sulle eccezioni di runtime e altro ancora. Per maggiori informazioni, consultare la sezione Panoramica di Application Insights.
Questa funzionalità offre opzioni di configurazione chiave che influiscono sulle prestazioni. L'elenco seguente descrive alcune delle impostazioni e considerazioni rilevanti per il monitoraggio e le prestazioni.
Abilitare il campionamento dei dati di telemetria: Per scenari con velocità effettiva elevata, valutare la quantità di dati di telemetria e informazioni necessarie. Provare a usare la funzionalità di campionamento dei dati di telemetria in Application Insights per evitare di ridurre le prestazioni della funzione con dati di telemetria e metriche non necessari.
Configurare le impostazioni di aggregazione: esaminare e configurare la frequenza di aggregazione e invio di dati ad Application Insights. Questa impostazione di configurazione si trova nel file host.json insieme a molte altre opzioni di campionamento e registrazione. Per altre informazioni, vedere Configurare l'aggregatore.
Quando Application Insights è abilitato senza campionamento, vengono inviati tutti i dati di telemetria. L'invio di dati su tutti gli eventi può avere un effetto negativo sulle prestazioni della funzione, soprattutto negli scenari di streaming di eventi a velocità effettiva elevata.
Sfruttare il campionamento e valutare continuamente la quantità appropriata di dati di telemetria necessari per il monitoraggio è fondamentale per ottenere prestazioni ottimali. I dati di telemetria devono essere usati per la valutazione generale dell'integrità della piattaforma e per la risoluzione dei problemi occasionali, non per acquisire le metriche aziendali principali. Per altre informazioni, vedere Configurare il campionamento.
Collegamento di output
Usare il binding di output Event Hubs per le Funzioni di Azure per semplificare la pubblicazione in un flusso di eventi da una funzione. I vantaggi dell'uso di questo binding includono:
Gestione delle risorse: Il binding gestisce automaticamente il ciclo di vita del client e della connessione e riduce il rischio di problemi legati all'esaurimento delle porte e alla gestione del pool di connessioni.
Meno codice: il binding astrae l'SDK sottostante e riduce la quantità di codice necessaria per pubblicare gli eventi. Consente di scrivere e gestire il codice con un minor numero di righe boilerplate.
Invio in batch: per diversi linguaggi, l'invio in batch è supportato per pubblicare in modo efficiente in un flusso di eventi. L'invio in batch può migliorare le prestazioni e semplificare il codice che invia gli eventi.
È consigliabile esaminare l'elenco dei linguaggi supportati da Funzioni e le guide per gli sviluppatori per tali linguaggi. La sezione Bindings per ogni linguaggio fornisce esempi dettagliati e documentazione.
Invio in batch durante la pubblicazione di eventi
Se la funzione pubblica solo un singolo evento, configurare l'associazione per restituire un valore. Questo approccio è utile se l'esecuzione della funzione termina sempre con un'istruzione che invia l'evento. Usare questa tecnica solo per le funzioni sincrone che restituiscono un solo evento.
L'invio in batch è consigliato per migliorare le prestazioni quando si inviano più eventi a un flusso. L'invio in batch consente al binding di pubblicare eventi nel modo più efficiente possibile.
Il supporto per l'uso dell'associazione di output per inviare più eventi a Hub eventi è disponibile in C#, Java, Python e JavaScript.
Generare più eventi con il modello in-process (C#)
Usare i tipi ICollector e IAsyncCollector quando si inviano più eventi da una funzione in C#.
ICollector<T>. Il metodo Add() può essere usato sia in funzioni sincrone che asincrone. Esegue l'operazione di aggiunta non appena viene invocato.
IAsyncCollector<T>. Il metodo AddAsync() prepara gli eventi da pubblicare nel flusso di eventi. Se si scrive una funzione asincrona, è consigliabile usare IAsyncCollector per gestire meglio gli eventi pubblicati.
Per esempi di uso di C# per pubblicare eventi singoli e multipli, vedere il binding di output di Event Hubs di Azure per le Funzioni di Azure.
Produrre più eventi con il modello di lavoro isolato (C#)
A seconda della versione del runtime di Funzioni, il modello di lavoro isolato supporta tipi diversi per i parametri passati all'associazione di output. Per più eventi, viene utilizzato un array per incapsulare l'insieme. È consigliabile esaminare gli attributi di associazione di output e i dettagli di utilizzo per il modello isolato e prendere nota delle differenze tra le versioni dell'estensione.
Limitazione e contropressione
Le considerazioni sul controllo della velocità si applicano alle associazioni di output, non solo per gli Hub di eventi, ma anche per i servizi di Azure, come Azure Cosmos DB. È importante acquisire familiarità con i limiti e le quote applicabili a tali servizi e pianificare di conseguenza.
Per gestire gli errori downstream con il modello in-process, è possibile eseguire il wrapping di AddAsync e FlushAsync in un gestore eccezioni per le funzioni .NET per rilevare le eccezioni da IAsyncCollector. Un'altra opzione consiste nell'usare direttamente gli SDK di Hub eventi anziché usare associazioni di output.
Se si usa il modello isolato per le funzioni, usare la gestione delle eccezioni strutturata in modo responsabile per intercettare le eccezioni quando si restituiscono i valori di output.
Codice della funzione
Questa sezione illustra le aree principali da considerare quando si scrive codice per elaborare gli eventi in una funzione attivata da Hub eventi.
Programmazione asincrona
È consigliabile scrivere la funzione per usare il codice asincrono ed evitare di bloccare le chiamate, soprattutto quando sono coinvolte chiamate di I/O.
Seguire queste linee guida quando si scrive una funzione che viene eseguita in modo asincrono:
Tutti asincroni o tutti sincroni: Se si configura una funzione per l'esecuzione asincrona, eseguire tutte le chiamate di I/O asincrone. Nella maggior parte dei casi, il codice parzialmente asincrono è peggiore del codice completamente sincrono. Scegliere asincrona o sincrona e usare l'opzione scelta in modo coerente.
Evitare di bloccare le chiamate: Il blocco delle chiamate torna al chiamante solo dopo il completamento della chiamata, a differenza delle chiamate asincrone, che restituiscono immediatamente. Un esempio in C# è la chiamata di Task.Result o Task.Wait su un'operazione asincrona.
Altre informazioni sul blocco delle chiamate
L'uso di chiamate di blocco per le operazioni asincrone può portare all'esaurimento del pool di thread e causare l'arresto anomalo del processo funzione. L'arresto anomalo si verifica perché una chiamata bloccante richiede la creazione di un altro thread per compensare la chiamata originale, che è in attesa. Di conseguenza, per completare l'operazione sono necessari il doppio del numero di thread.
Evitare questo approccio sync over async è particolarmente importante quando è coinvolto l'Event Hubs, perché un crash della funzione non aggiorna il checkpoint. La volta successiva che la funzione viene richiamata, potrebbe finire in questo ciclo e sembrare bloccata o procedere lentamente, poiché le esecuzioni della funzione finiscono per andare in timeout.
La risoluzione dei problemi di questo scenario inizia in genere con la revisione delle impostazioni del trigger e l'esecuzione di esperimenti, che possono comportare l'aumento del numero di partizioni. Le indagini possono anche causare la modifica di diverse opzioni di invio in batch, ad esempio la dimensione massima del batch o il numero di prelettura. L'impressione è che si tratti di un problema di velocità effettiva o di un'impostazione di configurazione che deve essere ottimizzata di conseguenza. Tuttavia, il problema principale si trova nel codice stesso ed è necessario risolverlo.
Contributors
Microsoft gestisce questo articolo. I seguenti collaboratori hanno scritto questo articolo.
Autore principale:
- David Barkol | GBB per le app di intelligenza artificiale
Per visualizzare i profili LinkedIn non pubblici, accedere a LinkedIn.
Passaggi successivi
Prima di continuare, prendere in considerazione la revisione di questi articoli correlati: