

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à.

# io/aurora\$1respond\$1to\$1client
<a name="ams-waits.respond-to-client"></a>

L’evento `io/aurora_respond_to_client` si verifica quando un thread è in attesa di restituire una serie di risultati a un client.

**Topics**
+ [Versioni del motore supportate](#ams-waits.respond-to-client.context.supported)
+ [Contesto](#ams-waits.respond-to-client.context)
+ [Probabili cause di aumento delle attese](#ams-waits.respond-to-client.causes)
+ [Azioni](#ams-waits.respond-to-client.actions)

## Versioni del motore supportate
<a name="ams-waits.respond-to-client.context.supported"></a>

Queste informazioni sull'evento di attesa sono supportate per le seguenti versioni del motore:
+ Aurora MySQL versione 2

## Contesto
<a name="ams-waits.respond-to-client.context"></a>

L'evento `io/aurora_respond_to_client` indica che un thread è in attesa di restituire una serie di risultati a un client.

L'elaborazione della query è completa e i risultati vengono restituiti al client dell'applicazione. Tuttavia, poiché non c'è abbastanza larghezza di banda di rete nel cluster del database, un thread è in attesa di restituire la serie di risultati.

## Probabili cause di aumento delle attese
<a name="ams-waits.respond-to-client.causes"></a>

Quando l’evento `io/aurora_respond_to_client` appare più che normale, possibilmente indicando un problema di prestazioni, le cause tipiche includono le seguenti:

**Classe di istanza database insufficiente per il carico di lavoro**  
La classe di istanza database utilizzata dal cluster del database non dispone della larghezza di banda di rete necessaria per elaborare il carico di lavoro in modo efficiente.

**Serie di risultati di grandi dimensioni**  
Si è verificato un aumento delle dimensioni della serie di risultati restituiti, poiché la query restituisce un numero maggiore di righe. La serie di risultati più ampia consuma una maggiore larghezza di banda di rete.

**Aumento del carico sul client**  
Potrebbe esserci pressione della CPU, pressione della memoria o saturazione della rete sul client. Un aumento del carico sul client ritarda la ricezione dei dati dal cluster del database di Aurora MySQL.

**Maggiore latenza di rete**  
Potrebbe esserci una maggiore latenza di rete tra il cluster del databalse di Aurora MySQL e il client. Una maggiore latenza di rete aumenta il tempo necessario per il client per la ricezione dei dati.

## Azioni
<a name="ams-waits.respond-to-client.actions"></a>

Consigliamo azioni diverse a seconda delle cause dell’evento di attesa.

**Topics**
+ [Identificare le sessioni e le query che causano gli eventi](#ams-waits.respond-to-client.actions.identify)
+ [Dimensionamento della classe dell’istanza database](#ams-waits.respond-to-client.actions.scale-db-instance-class)
+ [Verifica del carico di lavoro per risultati imprevisti](#ams-waits.respond-to-client.actions.workload)
+ [Distribuisci il carico di lavoro con le istanze del lettore](#ams-waits.respond-to-client.actions.balance)
+ [Utilizzare il modificatore SQL\$1BUFFER\$1RESULT](#ams-waits.respond-to-client.actions.sql-buffer-result)

### Identificare le sessioni e le query che causano gli eventi
<a name="ams-waits.respond-to-client.actions.identify"></a>

È possibile utilizzare Performance Insights per mostrare le query bloccate dall’evento di attesa `io/aurora_respond_to_client`. In genere, i database con carico da moderato a significativo hanno eventi di attesa. Gli eventi di attesa possono essere accettabili se le prestazioni sono ottimali. Se le prestazioni non sono ottimali, esaminare dove il database impiega più tempo. Considerare gli eventi di attesa che contribuiscono al carico più elevato per scoprire se è possibile ottimizzare il database e l'applicazione per ridurre tali eventi. 

**Per trovare query di SQL responsabili del carico elevato**

1. Accedi a Console di gestione AWS e apri la console Amazon RDS all'indirizzo [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).

1. Nel pannello di navigazione scegli **Approfondimenti sulle prestazioni**.

1. Scegli un'istanza database. Viene visualizzato il pannello di controllo di Approfondimenti sulle prestazioni per l'istanza database.

1. Nel grafico **Carico del database**, scegli **Dividi per attesa**.

1. Nella parte inferiore della pagina scegli **Prime Instruzioni SQL**.

   Il grafico elenca le query di SQL responsabili del carico. Quelli in cima all'elenco sono le più responsabili. Per risolvere un collo di bottiglia, occorre concentrarsi su queste istruzioni.

Per un'utile panoramica sulla risoluzione dei problemi con Performance Insights, consulta il post sul blog AWS Database [Analyze Amazon Aurora MySQL Workloads](https://aws.amazon.com/blogs/database/analyze-amazon-aurora-mysql-workloads-with-performance-insights/) with Performance Insights.

### Dimensionamento della classe dell’istanza database
<a name="ams-waits.respond-to-client.actions.scale-db-instance-class"></a>

Verifica l'aumento del valore delle CloudWatch metriche di Amazon relative al throughput di rete, ad esempio `NetworkReceiveThroughput` e. `NetworkTransmitThroughput` Se viene raggiunta la larghezza di banda di rete della classe di istanza database, è possibile dimensionare la classe di istanza database utilizzata dal cluster del database modificando il cluster del database. Una classe di istanze database con larghezza di banda di rete maggiore restituisce i dati ai client in modo più efficiente.

Per informazioni sul monitoraggio dei CloudWatch parametri di Amazon, consulta[Visualizzazione delle metriche nella console Amazon RDS](USER_Monitoring.md). Per informazioni sulle classi di istanza database, consulta [Classi di istanze DB Amazon Aurora](Concepts.DBInstanceClass.md). Per informazioni sulla modifica di un cluster di database, consulta [Modifica di un cluster database Amazon Aurora](Aurora.Modifying.md).

### Verifica del carico di lavoro per risultati imprevisti
<a name="ams-waits.respond-to-client.actions.workload"></a>

Controlla il carico di lavoro sul cluster del database e assicurati che non produca risultati imprevisti. Ad esempio, potrebbero esserci query che restituiscono un numero di righe più alto del previsto. In questo caso, puoi utilizzare i parametri del contatore di Performance Insights come `Innodb_rows_read`. Per ulteriori informazioni, consulta [Metriche contatore di Performance Insights](USER_PerfInsights_Counters.md).

### Distribuisci il carico di lavoro con le istanze del lettore
<a name="ams-waits.respond-to-client.actions.balance"></a>

È possibile distribuire il carico di lavoro di sola lettura con le repliche di Aurora. È possibile dimensionare orizzontalmente aggiungendo più repliche di Aurora. Ciò può comportare un aumento dei limiti per la larghezza di banda della rete. Per ulteriori informazioni, consulta [Cluster database Amazon Aurora](Aurora.Overview.md).

### Utilizzare il modificatore SQL\$1BUFFER\$1RESULT
<a name="ams-waits.respond-to-client.actions.sql-buffer-result"></a>

Puoi aggiungere il modificatore `SQL_BUFFER_RESULT` alle istruzioni `SELECT` per forzare il risultato in una tabella temporanea prima che vengano restituite al client. Questo modificatore può aiutare a risolvere i problemi di prestazioni quando i blocchi InnoDB non vengono liberati perché le query sono presenti nello stato di attesa `io/aurora_respond_to_client`. Per ulteriori informazioni, consulta [Istruzione SELECT](https://dev.mysql.com/doc/refman/5.7/en/select.html) nella documentazione di MySQL.