Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
# Contropressione
Flink utilizza la contropressione per adattare la velocità di elaborazione dei singoli operatori.
L'operatore può avere difficoltà a continuare a elaborare il volume di messaggi che riceve per diverse ragioni. L'operazione può richiedere più risorse della CPU di quante ne abbia a disposizione l'operatore. L'operatore può attendere il completamento I/O delle operazioni. Se un operatore non è in grado di elaborare rapidamente gli eventi, crea una contropressione negli operatori a monte che alimentano l'operatore lento. Ciò causa un rallentamento degli operatori a monte, il che può propagare ulteriormente la contropressione alla fonte e far sì che la sorgente si adatti alla velocità di trasmissione effettiva complessiva dell'applicazione, rallentando anche quest'ultima. Per una descrizione più approfondita della contropressione e del suo funzionamento, consulta [Come Apache Flink™ gestisce la contropressione](https://www.ververica.com/blog/how-flink-handles-backpressure).
Individuare gli operatori più lenti all'interno di un'applicazione consente di ottenere informazioni fondamentali per comprendere la causa principale dei problemi di prestazioni dell'applicazione. Le informazioni relative alla contropressione sono [rese visibili tramite la dashboard di Flink](https://nightlies.apache.org/flink/flink-docs-stable/docs/ops/monitoring/back_pressure/). Per identificare l'operatore lento è sufficiente individuare quello con un valore di contropressione elevato più vicino a un sink (l'operatore B, nell'esempio seguente). L'operatore responsabile dei rallentamenti è uno degli operatori a valle (l'operatore C nell'esempio). A causa della contropressione l'operatore B non è in grado di inoltrare l'output a C, l'operatore lento a causa del quale non riesce a elaborare gli eventi in maniera rapida.
```
A (backpressured 93%) -> B (backpressured 85%) -> C (backpressured 11%) -> D (backpressured 0%)
```
Una volta identificato l'operatore lento, prova a individuare i motivi di tale fenomeno. Talvolta le ragioni potrebbero essere molteplici e l'individuazione del problema rivelarsi complessa, tanto da richiedere diversi giorni dedicati ad attività di debugging e profilazione. Di seguito sono riportati alcune delle cause più ovvie e comuni, alcune delle quali sono ulteriormente descritte di seguito:
+ l'operatore esegue un I/O lento, ad esempio chiamate di rete (valuta di ricorrere all'utilizzo di AsyncIO);
+ C'è un'inclinazione nei dati e un operatore riceve più eventi degli altri (verifica esaminando il numero di messaggi in/out delle singole sottoattività (ad esempio, istanze dello stesso operatore) nella dashboard di Flink.
+ Si tratta di un'operazione che richiede molte risorse (se non vi è alcuna distorsione dei dati, è consigliabile utilizzare la scalabilità orizzontale per il lavoro legato o l'aumento per il lavoro CPU/memory legato) `ParallelismPerKPU` I/O
+ Log dettagliato nell'operatore: è consigliabile ridurlo al minimo per le applicazioni di produzione o considerare, invece, di inviare l'output di debug a un flusso di dati.
## Test della produttività con Discarding Sink
Il [discarding sink](https://nightlies.apache.org/flink/flink-docs-stable/api/java/org/apache/flink/streaming/api/functions/sink/DiscardingSink.html) ignora tutti gli eventi che riceve mentre l'applicazione è ancora in esecuzione (un'applicazione senza sink non può essere eseguita). Si rivela estremamente utile per effettuare test e profilazioni della velocità di trasmissione effettiva, nonché per verificare il corretto dimensionamento dell'applicazione. Si tratta inoltre di un controllo di integrità estremamente pragmatico, atto a verificare se a causare la contropressione siano i sink o l'applicazione. Limitarsi a effettuare un controllo dei parametri di contropressione, tuttavia, rappresenta spesso la soluzione più semplice e diretta.
Sostituire tutti i sink di un'applicazione con un discarding sink e creare una fonte fittizia che genera dati simili a quelli di produzione consente di misurare la massima velocità di trasmissione effettiva dell'applicazione relativamente a una determinata impostazione di parallelismo. È inoltre possibile aumentare il parallelismo per verificare che l'applicazione si dimensioni in maniera corretta e non presenti ostacoli che emergono solo a velocità di trasmissione effettiva più elevate (ad esempio, a causa del disallineamento dei dati).