Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
# io/aurora\$1respond\$1to\$1client
L'événement `io/aurora_respond_to_client` se produit lorsqu'un thread attend de renvoyer un ensemble de résultats à un client.
**Topics**
+ [Versions de moteur prises en charge](#ams-waits.respond-to-client.context.supported)
+ [Contexte](#ams-waits.respond-to-client.context)
+ [Causes probables de l'augmentation du nombre d'événements d'attente](#ams-waits.respond-to-client.causes)
+ [Actions](#ams-waits.respond-to-client.actions)
## Versions de moteur prises en charge
Ces informations relatives aux événements d’attente sont prises en charge pour les versions de moteur suivantes :
+ Aurora MySQL version 2
## Contexte
L'événement `io/aurora_respond_to_client` indique qu'un thread attend de renvoyer un ensemble de résultats à un client.
Le traitement des requêtes est terminé et les résultats sont renvoyés au client de l'application. Toutefois, la bande passante réseau sur le cluster de bases de données étant insuffisante, un thread attend de renvoyer l'ensemble de résultats.
## Causes probables de l'augmentation du nombre d'événements d'attente
Lorsque l'événement `io/aurora_respond_to_client` se produit plus souvent qu'à l'accoutumée, indiquant un possible problème de performance, les causes sont généralement les suivantes :
**Classe d'instance de base de données insuffisante pour la charge de travail**
La classe d'instance de base de données utilisée par le cluster de bases de données ne dispose pas de suffisamment de bande passante réseau pour traiter efficacement la charge de travail.
**Ensembles de résultats volumineux**
La taille de l'ensemble de résultats renvoyé a augmenté, car la requête renvoie un nombre plus élevé de lignes. L'ensemble de résultats plus volumineux consomme davantage de bande passante réseau.
**Charge accrue sur le client**
Le client peut être soumis à une pression exercée sur l'UC, la mémoire ou à une saturation du réseau. Une augmentation de la charge exercée sur le client retarde la réception des données du cluster de bases de données Aurora MySQL.
**Latence réseau accrue**
La latence réseau peut être accrue entre le cluster de bases de données Aurora MySQL et le client. Une latence réseau plus élevée augmente le temps nécessaire au client pour recevoir les données.
## Actions
Nous vous recommandons différentes actions en fonction des causes de votre événement d’attente.
**Topics**
+ [Identifier les sessions et les requêtes à l'origine des événements](#ams-waits.respond-to-client.actions.identify)
+ [Mettre à l'échelle la classe d'instance de base de données](#ams-waits.respond-to-client.actions.scale-db-instance-class)
+ [Vérifier la charge de travail pour trouver des résultats inattendus](#ams-waits.respond-to-client.actions.workload)
+ [Distribuer la charge de travail entre les instances de lecture](#ams-waits.respond-to-client.actions.balance)
+ [Utiliser le modificateur SQL\$1BUFFER\$1RESULT](#ams-waits.respond-to-client.actions.sql-buffer-result)
### Identifier les sessions et les requêtes à l'origine des événements
Vous pouvez utiliser Performance Insights pour afficher les requêtes bloquées par l'événement d'attente `io/aurora_respond_to_client`. En règle générale, les bases de données à charge modérée à importante présentent des événements d'attente. Les événements d'attente peuvent être acceptables si les performances sont optimales. Si les performances ne sont pas optimales, voyez où la base de données passe le plus de temps. Examinez les événements d'attente qui contribuent à la charge la plus élevée et voyez si vous pouvez optimiser la base de données et l'application afin de réduire ces événements.
**Pour rechercher les requêtes SQL responsables d’une charge élevée**
1. Connectez-vous à la console Amazon RDS AWS Management Console et ouvrez-la à [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)l'adresse.
1. Dans le panneau de navigation, choisissez **Performance Insights**.
1. Choisissez une instance de base de données. Le tableau de bord Performance Insights s’affiche pour cette instance de base de données.
1. Dans le graphique **Database load (Charge de base de données)**, choisissez **Slice by wait (Tranche par attente)**.
1. Au bas de la page, choisissez **Top SQL (Principaux éléments SQL)**.
Le graphique répertorie les requêtes SQL responsables de la charge. Les requêtes situées en haut de la liste sont les plus responsables. Pour résoudre un goulet d’étranglement, concentrez-vous sur ces instructions.
Pour une présentation utile du dépannage à l'aide de Performance Insights, consultez le billet de blog AWS consacré à la base de données [Analyze Amazon Aurora MySQL Workloads with Performance Insights](https://aws.amazon.com/blogs/database/analyze-amazon-aurora-mysql-workloads-with-performance-insights/).
### Mettre à l'échelle la classe d'instance de base de données
Vérifiez l'augmentation de la valeur des CloudWatch métriques Amazon liées au débit du réseau, telles que `NetworkReceiveThroughput` et`NetworkTransmitThroughput`. Si la bande passante réseau de la classe d'instance de base de données est atteinte, vous pouvez mettre à l'échelle la classe d'instance de base de données utilisée par le cluster de bases de données. Une classe d'instance de base de données dotée d'une bande passante réseau plus importante renvoie les données aux clients plus efficacement.
Pour plus d'informations sur le suivi CloudWatch des métriques Amazon, consultez[Affichage des métriques dans la console Amazon RDS](USER_Monitoring.md). Pour plus d’informations sur les classes d’instance de base de données, consultez [Classes d'instances de base de données Amazon Aurora](Concepts.DBInstanceClass.md). Pour plus d’informations sur la modification d’un cluster de bases de données, consultez [Modification d’un cluster de bases de données Amazon Aurora](Aurora.Modifying.md).
### Vérifier la charge de travail pour trouver des résultats inattendus
Vérifiez la charge de travail sur le cluster de bases de données et assurez-vous qu'elle ne produit pas de résultats inattendus. Par exemple, certaines requêtes peuvent renvoyer un nombre de lignes plus élevé que prévu. Si tel est le cas, vous pouvez utiliser des métriques de compteur Performance Insights telles que `Innodb_rows_read`. Pour de plus amples informations, veuillez consulter [Métrique de compteur de Performance Insights](USER_PerfInsights_Counters.md).
### Distribuer la charge de travail entre les instances de lecture
Vous pouvez distribuer la charge de travail en lecture seule entre les réplicas Aurora. Vous pouvez procéder à une mise à l'échelle horizontale en ajoutant d'autres réplicas Aurora. Cela peut entraîner une augmentation des limites de bande passante réseau. Pour de plus amples informations, veuillez consulter [Clusters de bases de données Amazon Aurora](Aurora.Overview.md).
### Utiliser le modificateur SQL\$1BUFFER\$1RESULT
Vous pouvez ajouter le modificateur `SQL_BUFFER_RESULT` aux instructions `SELECT` pour forcer les résultats dans une table temporaire avant qu'ils ne soient renvoyés au client. Ce modificateur facilite la résolution des problèmes de performances lorsque les verrous InnoDB ne sont pas libérés, car des requêtes se trouvent dans l'état d'attente `io/aurora_respond_to_client`. Pour en savoir plus, consultez [SELECT Statement](https://dev.mysql.com/doc/refman/5.7/en/select.html) dans la documentation MySQL.