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.
# Modèles de conception des bonnes pratiques : optimisation des performances d’Amazon S3
Vos applications peuvent facilement exécuter des milliers de transactions par seconde lors du chargement et de l’extraction du stockage depuis Amazon S3. Amazon S3 se met automatiquement à l’échelle en fonction des taux de demandes très importants. Par exemple, votre application peut traiter au moins 3 500 PUT/COPY/POST/DELETE or 5,500 GET/HEAD demandes par seconde par préfixe Amazon S3 partitionné. Il n’existe aucune limite au nombre de préfixes dans un compartiment. Vous pouvez augmenter vos performances de lecture et d’écriture en effectuant une mise en parallèle. Par exemple, si vous créez 10 préfixes dans un compartiment Amazon S3 pour paralléliser les lectures, vous pouvez adapter vos performances de lecture à 55 000 demandes de lecture par seconde. De même, vous pouvez mettre à l’échelle les opérations d’écriture en écrivant sur plusieurs préfixes. Dans le cas des opérations de lecture et d’écriture, la mise à l’échelle se fait progressivement et n’est pas instantanée. Les performances réelles varient en fonction des caractéristiques de la charge de travail, des modèles d’utilisation et de la configuration du système. Pendant la mise à l’échelle d’Amazon S3 à votre nouveau taux de demandes plus élevé, vous pouvez rencontrer des erreurs 503 (Ralentissement). Ces erreurs disparaissent une fois la mise à l’échelle terminée. Pour plus d’informations sur la création et l’utilisation de préfixes, consultez [Organisation des objets à l’aide de préfixes](using-prefixes.md).
Certaines applications de lacs de données sur Amazon S3 analysent des milliards d’objets pour les requêtes qui portent sur des péta-octets de données. Ces applications de lac de données atteignent des taux de transfert à instance unique qui maximisent l'utilisation de l'interface réseau pour leur instance [Amazon](https://docs.aws.amazon.com/ec2/index.html) EC2, qui peut atteindre Gb/s 100 sur une seule instance. Ces applications regroupent ensuite le débit de plusieurs instances pour parvenir à plusieurs téraoctets par seconde.
D’autres applications sont sensibles à la latence, comme les applications de messagerie des réseaux sociaux. Ces applications peuvent atteindre des latences constantes pour les petits objets (et les first-byte-out latences pour les objets plus grands) d'environ 100 à 200 millisecondes.
D'autres AWS services peuvent également contribuer à accélérer les performances de différentes architectures d'applications. Par exemple, si vous souhaitez des taux de transfert plus élevés sur une seule connexion HTTP ou des latences à un chiffre en millisecondes, utilisez Amazon CloudFront ou [Amazon](https://docs.aws.amazon.com/cloudfront/index.html) pour la mise en cache avec [ ElastiCacheAmazon](https://docs.aws.amazon.com/elasticache/index.html) S3.
De plus, si vous souhaitez un transport rapide de données sur de longues distances entre un client et un compartiment S3, utilisez [Configuration de transferts de fichiers rapides et sécurisés à l’aide d’Amazon S3 Transfer Acceleration](transfer-acceleration.md). Transfer Acceleration utilise les emplacements périphériques répartis dans le monde entier CloudFront pour accélérer le transport des données sur des distances géographiques. Si votre charge de travail Amazon S3 utilise le chiffrement côté serveur avec AWS KMS, consultez la section [AWS KMS Limites](https://docs.aws.amazon.com/kms/latest/developerguide/limits.html) du guide du AWS Key Management Service développeur pour obtenir des informations sur les taux de demandes pris en charge pour votre cas d'utilisation.
Les rubriques suivantes décrivent les instructions et les modèles de conception des bonnes pratiques pour optimiser les performances des applications qui utilisent Amazon S3. Veuillez consulter [Recommandations de performance pour Amazon S3](optimizing-performance-guidelines.md) et [Modèles de conception des performances pour Amazon S3](optimizing-performance-design-patterns.md) pour obtenir les informations les plus à jour sur l’optimisation des performances pour Amazon S3.
**Note**
Pour plus d’informations sur l’utilisation de la classe de stockage Amazon S3 Express One Zone avec des compartiments de répertoires, consultez [S3 Express One Zone](directory-bucket-high-performance.md#s3-express-one-zone) et [Utilisation des compartiments de répertoires](directory-buckets-overview.md).
**Topics**
+ [Recommandations de performance pour Amazon S3](optimizing-performance-guidelines.md)
+ [Modèles de conception des performances pour Amazon S3](optimizing-performance-design-patterns.md)
# Recommandations de performance pour Amazon S3
Lors du développement d’applications qui téléchargent et extraient les objets depuis Amazon S3, suivez nos instructions sur les bonnes pratiques pour optimiser les performances. Nous proposons également des [Modèles de conception des performances pour Amazon S3 ](optimizing-performance-design-patterns.md) plus détaillés.
Pour obtenir les meilleures performances pour votre application sur Amazon S3, nous recommandons les directives suivantes.
**Topics**
+ [Mesurer les performances](#optimizing-performance-guidelines-measure)
+ [Mise à l’échelle horizontale des connexions de stockage](#optimizing-performance-guidelines-scale)
+ [Utilisation des extractions de plages d’octets](#optimizing-performance-guidelines-get-range)
+ [Nouvelle tentative de demandes pour les applications sensibles à la latence](#optimizing-performance-guidelines-retry)
+ [Combinez Amazon S3 (stockage) et Amazon EC2 (calcul) dans un même appareil Région AWS](#optimizing-performance-guidelines-combine)
+ [Utilisation d’Amazon S3 Transfer Acceleration pour réduire la latence provoquée par la distance](#optimizing-performance-guidelines-acceleration)
+ [Utilisez la dernière version du AWS SDKs](#optimizing-performance-guidelines-sdk)
## Mesurer les performances
Lors de l’optimisation des performances, examinez le débit du réseau, l’UC et les exigences DRAM. Selon les mélange des demandes de ces différentes ressources, il peut valoir la peine d’évaluer différents types d’instance [Amazon EC2](https://docs.aws.amazon.com/ec2/index.html). Pour plus d’informations sur les types d’instances, consultez [Types d’instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html) dans le *Guide de l’utilisateur Amazon EC2*.
Il peut aussi être utile d’examiner le temps de recherche DNS, la latence et la vitesse de transfert des données à l’aide des outils d’analyse HTTP lors de la mesure des performances.
Pour comprendre les exigences de performances et optimiser les performances de votre application, vous pouvez également surveiller les réponses d’erreur 503 que vous recevez. La surveillance de certaines métriques de performances peut entraîner des dépenses supplémentaires. Pour plus d’informations, consultez [Tarification Amazon S3](https://aws.amazon.com/s3/pricing/).
### Surveillance du nombre de réponses d’erreur de statut 503 (Ralentissement)
Pour surveiller le nombre de réponses d’erreur de statut 503 que vous recevez, vous pouvez utiliser l’une des options suivantes :
+ Utilisez les métriques de CloudWatch demande Amazon pour Amazon S3. Les métriques de CloudWatch demande incluent une métrique pour les réponses d'état 5xx. Pour plus d'informations sur les métriques de demande CloudWatch , consultez [Surveillance des métriques avec Amazon CloudWatch](cloudwatch-monitoring.md).
+ Utilisez le nombre d’erreurs 503 (Service non disponible) disponible dans la section des métriques avancées d’Amazon S3 Storage Lens. Pour plus d’informations, consultez [Utilisation de métriques S3 Storage Lens pour améliorer les performances](storage-lens-detailed-status-code.md).
+ Utilisez la journalisation des accès au serveur Amazon S3. La journalisation des accès au serveur vous permet de filtrer et de passer en revue toutes les demandes qui reçoivent des réponses 503 (Erreur interne). Vous pouvez également utiliser Amazon Athena pour analyser les journaux. Pour en savoir plus sur la journalisation des accès au serveur, consultez [Enregistrement de demandes avec journalisation des accès au serveur](ServerLogs.md).
En surveillant le nombre de codes d’erreur de statut HTTP 503, vous pouvez souvent obtenir des insights précieux sur les préfixes, les clés ou les compartiments qui reçoivent le plus de demandes de limitation.
## Mise à l’échelle horizontale des connexions de stockage
La répartition des demandes entre plusieurs connexions est un modèle de conception courant pour mettre horizontalement à l’échelle les performances. Lorsque vous développez des applications hautes performances, pensez à Amazon S3 comme à un très grand système réparti, et non comme un simple point de terminaison réseau, tel qu’un serveur de stockage traditionnel. Vous pouvez atteindre les meilleures performances en adressant plusieurs demandes concurrentes à Amazon S3. Répartissez ces demandes sur des connexions distinctes pour maximiser la bande passante accessible à partir d’Amazon S3. Amazon S3 n’a aucune limite pour le nombre de connexions à votre compartiment.
## Utilisation des extractions de plages d’octets
Avec l’en-tête HTTP `Range` dans une demande [GET Object](https://docs.aws.amazon.com/AmazonS3/latest/API/RESTObjectGET.html), vous pouvez extraire une plage d’octets d’un objet, en ne transférant que la portion spécifiée. Vous pouvez utiliser des connexions simultanées vers Amazon S3 pour extraire différentes plages d’octets depuis le même objet. Vous pouvez ainsi parvenir au regroupement de débits le plus élevé, par opposition à une seule demande d’objet entier. L’extraction des plages les plus petites d’un grand objet permet aussi à votre application d’améliorer l’intervalle des nouvelles tentatives quand les demandes sont interrompues. Pour de plus amples informations, veuillez consulter [Téléchargement d’objets](download-objects.md).
Si les objets sont l’objet d’une opération PUT à l’aide d’un chargement en plusieurs parties, une bonne pratique consiste à les soumettre à une opération GET dans les mêmes tailles d’élément (ou au moins alignées sur les frontières d’élément) pour obtenir de meilleures performances. Les demandes GET peuvent directement adresser les éléments individuels ; par exemple, `GET ?partNumber=N.`
## Nouvelle tentative de demandes pour les applications sensibles à la latence
Les expirations et les nouvelles tentatives agressives permettent d’obtenir une latence cohérente. Étant donnée la large échelle d’Amazon S3, si la première demande est lente, une demande de nouvelle tentative est susceptible d’emprunter un chemin différent et de réussir rapidement. Ils AWS SDKs ont des valeurs de délai d'expiration et de nouvelle tentative configurables que vous pouvez ajuster en fonction des tolérances de votre application spécifique.
## Combinez Amazon S3 (stockage) et Amazon EC2 (calcul) dans un même appareil Région AWS
Même si les noms de compartiment S3 sont globalement uniques, chaque compartiment est stocké dans une région que vous sélectionnez lorsque vous créez le compartiment. Pour en savoir plus sur les directives relatives à la dénomination des compartiments, consultez [Présentation des compartiments](https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingBucket.html) et [Règles de dénomination des compartiments](https://docs.aws.amazon.com/AmazonS3/latest/userguide/bucketnamingrules.html). Pour optimiser les performances, nous vous recommandons d'accéder au compartiment à partir des instances Amazon EC2 de la même manière Région AWS lorsque cela est possible. Cela permet de réduire la latence réseau et les coûts de transfert des données.
Pour plus d’informations sur la tarification du transfert des données, consultez la [Tarification Amazon S3](https://aws.amazon.com/s3/pricing/).
## Utilisation d’Amazon S3 Transfer Acceleration pour réduire la latence provoquée par la distance
[Configuration de transferts de fichiers rapides et sécurisés à l’aide d’Amazon S3 Transfer Acceleration](transfer-acceleration.md) permet un transfert rapide, facile et sécurisé des fichiers sur des longues distances entre votre client et un compartiment S3. Transfer Acceleration tire parti des emplacements périphériques répartis dans le monde entier [sur Amazon CloudFront](https://docs.aws.amazon.com/cloudfront/index.html). Lorsque les données arrivent dans un emplacement périphérique, elles sont transférées vers Amazon S3 sur un chemin de réseau optimisé. Transfer Acceleration convient parfaitement au transfert régulier de gigaoctets ou téraoctets de données d’un continent à l’autre. Il est aussi utile pour les clients qui chargent sur un compartiment centralisé depuis le monde entier.
Vous pouvez utiliser l’[outil de comparaison de vitesse Amazon S3 Transfer Acceleration](https://s3-accelerate-speedtest.s3-accelerate.amazonaws.com/en/accelerate-speed-comparsion.html) pour comparer les vitesses de chargement accéléré et non accéléré dans les régions Amazon S3. L’outil de comparaison de la vitesse utilise les chargements partitionnés pour transférer un fichier à partir de votre navigateur vers différentes régions Amazon S3 avec ou sans Amazon S3 Transfer Acceleration.
## Utilisez la dernière version du AWS SDKs
Ils AWS SDKs fournissent un support intégré pour de nombreuses directives recommandées pour optimiser les performances d'Amazon S3. Ils SDKs fournissent une API plus simple pour tirer parti d'Amazon S3 depuis une application et sont régulièrement mis à jour pour suivre les meilleures pratiques les plus récentes. Par exemple, ils SDKs incluent une logique permettant de réessayer automatiquement les requêtes en cas d'erreur HTTP 503 et investissent dans du code pour répondre et s'adapter aux connexions lentes.
Ils fournissent SDKs également le [gestionnaire de transfert](https://docs.aws.amazon.com/sdk-for-java/latest/developer-guide/examples-s3-transfermanager.html), qui automatise le dimensionnement horizontal des connexions pour traiter des milliers de demandes par seconde, en utilisant des requêtes par plage d'octets le cas échéant. Il est important d'utiliser la dernière version du AWS SDKs pour obtenir les dernières fonctionnalités d'optimisation des performances.
Vous pouvez aussi optimiser les performances lorsque vous utilisez les demandes d’API REST HTTP. Lorsque vous utilisez l'API REST, vous devez suivre les mêmes bonnes pratiques que celles incluses dans le SDKs. Autorisez les délais d’expiration et les nouvelles tentatives sur les demandes lentes, et multipliez les connexions pour autoriser l’extraction de données d’objet en parallèle. Pour plus d’informations sur l’utilisation de l’API REST, consultez la [Référence d’API Amazon Simple Storage Service](https://docs.aws.amazon.com/AmazonS3/latest/API/).
# Modèles de conception des performances pour Amazon S3
Lors de la conception d’applications pour télécharger et extraire des objets depuis Amazon S3, utilisez nos modèles de conception des bonnes pratiques pour parvenir aux meilleures performances de votre application. Nous vous proposons aussi de prendre en compte des [Recommandations de performance pour Amazon S3 ](optimizing-performance-guidelines.md) lors de la planification de l’architecture de votre application.
Pour optimiser les performances, vous pouvez utiliser les modèles de conception suivants.
**Topics**
+ [Utilisation de la mise en cache pour le contenu consulté fréquemment](#optimizing-performance-caching)
+ [Délais d’expiration et nouvelles tentatives pour les applications sensibles à la latence](#optimizing-performance-timeouts-retries)
+ [Mise à l’échelle horizontale et mise en parallèle des demandes pour le haut débit](#optimizing-performance-parallelization)
+ [Utilisation d’Amazon S3 Transfer Acceleration pour accélérer les transferts de données disparates géographiquement](#optimizing-performance-acceleration)
+ [Optimisation pour les charges de travail à taux de demandes élevés](#optimizing-performance-high-request-rate)
## Utilisation de la mise en cache pour le contenu consulté fréquemment
La plupart des applications qui stockent des données dans Amazon S3 traitent un « ensemble opérationnel » de données, demandé à maintes reprises par les utilisateurs. Si une charge de travail envoie des requêtes GET répétées pour un ensemble commun d'objets, vous pouvez utiliser un cache tel qu'[Amazon CloudFront](https://docs.aws.amazon.com/cloudfront/index.html) ElastiCache, [Amazon](https://docs.aws.amazon.com/elasticache/index.html) ou [AWS Elemental MediaStore](https://docs.aws.amazon.com/mediastore/index.html)pour optimiser les performances. L’adoption réussie du cache peut se traduire par une latence faible et des taux élevés de transfert des données. Les applications qui utilisent la mise en cache envoient aussi moins de demandes directes à Amazon S3, ce qui peut aider à réduire les coûts des demandes.
Amazon CloudFront est un réseau de diffusion de contenu rapide (CDN) qui met en cache de manière transparente les données d'Amazon S3 dans un grand nombre de points de présence répartis géographiquement (). PoPs Lorsque des objets sont accessibles depuis plusieurs régions ou via Internet, cela CloudFront permet aux données d'être mises en cache à proximité des utilisateurs qui accèdent aux objets. Il peut en résulter une diffusion haute performance des contenus Amazon S3 réputés. Pour plus d'informations à ce sujet CloudFront, consultez le manuel [Amazon CloudFront Developer Guide](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/).
Amazon ElastiCache est un cache en mémoire géré. Avec ElastiCache, vous pouvez provisionner des instances Amazon EC2 qui mettent en cache des objets en mémoire. Cette mise en cache se traduit par des ordres de réduction de magnitude dans la latence GET et de substantielles augmentations dans le débit de téléchargement. Pour l'utiliser ElastiCache, vous modifiez la logique de l'application pour remplir le cache avec des objets chauds et vérifier la présence d'objets chauds dans le cache avant de les demander à Amazon S3. Pour des exemples d'utilisation visant ElastiCache à améliorer les performances GET d'Amazon S3, consultez le billet de blog [Turbocharger Amazon S3 avec Amazon ElastiCache pour Redis](https://aws.amazon.com/blogs/storage/turbocharge-amazon-s3-with-amazon-elasticache-for-redis/).
AWS Elemental MediaStore est un système de mise en cache et de distribution de contenu spécialement conçu pour les flux de travail vidéo et la diffusion de contenu multimédia à partir d'Amazon S3. MediaStore fournit un end-to-end stockage APIs spécifique pour les vidéos et est recommandé pour les charges de travail vidéo sensibles aux performances. Pour plus d'informations à ce sujet MediaStore, consultez le [guide de AWS Elemental MediaStore l'utilisateur](https://docs.aws.amazon.com/mediastore/latest/ug/).
## Délais d’expiration et nouvelles tentatives pour les applications sensibles à la latence
Dans certaines situations, une application reçoit une réponse d’Amazon S3 indiquant qu’une nouvelle tentative est nécessaire. Amazon S3 mappe les noms de compartiment et d’objet aux données d’objet qui leur sont associées. Si une application génère des taux de demande élevés (généralement des taux soutenus de plus de 5 000 demandes par seconde pour un petit nombre d’objets), elle peut recevoir des réponses HTTP 503 *slowdown*. Si ces erreurs se produisent, chaque kit AWS SDK implémente une logique de nouvelle tentative automatique à l’aide d’une interruption exponentielle. Si vous n’utilisez pas de kit AWS SDK, vous devez implémenter une logique de nouvelle tentative lors de la réception de l’erreur HTTP 503. Pour plus d'informations sur les techniques de réduction, consultez la section [Comportement des nouvelles tentatives](https://docs.aws.amazon.com/sdkref/latest/guide/feature-retry-behavior.html) dans le guide de *référence des outils AWS SDKs et*.
Amazon S3 se met automatiquement à l’échelle en réponse aux taux soutenus de nouvelles demandes, optimisant dynamiquement les performances. Tandis qu’Amazon S3 optimise en interne le taux de nouvelles demandes, vous recevez temporairement des réponses HTTP 503 jusqu’à ce que l’optimisation soit terminée. Après qu’Amazon S3 optimise en interne les performances pour le nouveau taux de demandes, toutes les demandes sont généralement traitées sans nouvelles tentatives.
Pour les applications sensibles à la latence, Amazon S3 conseille un suivi et des opérations de nouvelles tentatives plus lentes. Lorsque vous retentez une demande, nous recommandons l’utilisation d’une nouvelle connexion à Amazon S3 et l’exécution d’une nouvelle recherche DNS.
Lorsque vous effectuez des demandes volumineuses de taille variable (par exemple, plus de 128 Mo), nous conseillons de suivre le débit obtenu et de procéder à de nouvelles tentatives sur les 5 % les plus lents des demandes. Lorsque vous exécutez des demandes plus petites (par exemple, inférieures à 512 Ko), où les latences médianes sont souvent dans une plage de dix millisecondes, une bonne instruction consiste à retenter une opération GET ou PUT après 2 secondes. Si de nouvelles tentatives sont nécessaires, la bonne pratique consiste à se retirer. Par exemple, nous recommandons de n’émettre une nouvelle tentative qu’après 2 secondes et une deuxième nouvelle tentative au bout de 4 secondes supplémentaires.
Si votre application adresse des demandes de taille fixe à Amazon S3, vous devez escompter des temps de réponse plus cohérents pour chacune de ces demandes. Dans ce cas, une stratégie simple consiste à identifier le 1 % de demandes les plus lentes et de les réessayer. Même une simple nouvelle tentative est fréquemment efficace pour réduire la latence.
Si vous utilisez AWS Key Management Service (AWS KMS) pour le chiffrement côté serveur, consultez la section [Quotas](https://docs.aws.amazon.com/kms/latest/developerguide/limits.html) du *guide du AWS Key Management Service développeur* pour obtenir des informations sur les taux de demandes pris en charge pour votre cas d'utilisation.
## Mise à l’échelle horizontale et mise en parallèle des demandes pour le haut débit
Amazon S3 est un système distribué très large. Pour vous aider à tirer parti de son échelle, nous vous encourageons à horizontalement mettre à l’échelle les demandes parallèles adressées aux points de terminaison du service Amazon S3. En plus de la distribution des demandes au sein d’Amazon S3, ce type d’approche de la mise à l’échelle permet de répartir la charge sur plusieurs chemins d’accès du réseau.
Pour les transferts à haut débit, Amazon S3 conseille l’utilisation d’applications employant plusieurs connexions pour exécuter des opérations GET ou PUT sur les données en parallèle. Par exemple, cela est pris en charge par [Amazon S3 Transfer Manager](https://docs.aws.amazon.com/sdk-for-java/latest/developer-guide/transfer-manager.html) dans le SDK AWS Java, et la plupart des autres AWS SDKs proposent des constructions similaires. Pour certaines applications, vous pouvez obtenir des connexions parallèles en lançant plusieurs demandes simultanément dans différents threads d’application ou dans différentes instances d’application. La meilleure approche à adopter dépend de votre application et de la structure des objets auxquels vous accédez.
Vous pouvez utiliser le AWS SDKs pour émettre directement des requêtes GET et PUT plutôt que d'utiliser la gestion des transferts dans le AWS SDK. Cette approche vous permet d’affiner votre charge de travail plus directement, tout en tirant profit du support du kit SDK pour les nouvelles tentatives et sa gestions des réponses HTTP 503 qui peuvent se produire. En règle générale, lorsque vous téléchargez des objets volumineux depuis Amazon S3, nous vous conseillons de faire des demandes simultanées afin de maximiser le débit du réseau et d'optimiser les performances de téléchargement. Vous pouvez y parvenir en demandant des plages d'octets spécifiques à l'objet ou en téléchargeant simultanément des parties individuelles d'un objet en plusieurs parties. Cette approche de téléchargement parallèle permet d'utiliser pleinement la capacité de votre carte d'interface réseau (NIC). Pour les objets qui ont été chargés en plusieurs parties, nous vous recommandons de les télécharger en utilisant les mêmes tailles de pièces ou d'aligner les demandes sur les limites des pièces d'origine pour de meilleures performances. Cette méthode de téléchargement simultané fournit un débit global supérieur à celui des demandes portant sur un seul objet entier.
La mesure des performances est importante quand vous réglez le nombre de demandes à émettre simultanément. Il est recommandé de commencer avec une seule demande à la fois. Mesurez la bande passante réseau obtenue et l’utilisation des autres ressources que votre application utilise dans le traitement des données. Vous pouvez alors identifier la ressource du goulet d’étranglement (à savoir, la ressource avec l’utilisation la plus élevée), et de là le nombre de requêtes susceptibles d’être utiles. Par exemple, si le traitement d’une demande à la fois conduit à une utilisation de l’UC de 25 %, cela induit que quatre demandes simultanées au plus peuvent être accueillies. Les mesures sont essentielles et il vaut la peine de confirmer l’utilisation des ressources tandis que le taux des demandes augmente.
Si votre application adresse directement des demandes à Amazon S3 à l’aide de l’API REST, nous recommandons l’utilisation d’un groupe de connexions HTTP et la réutilisation de chaque connexion pour un ensemble de demandes. Le fait d’éviter la configuration des connexions par demande supprime la nécessité d’exécuter des liaisons TCP à démarrage lent et SSL (Secure Sockets Layer) sur chaque demande. Pour plus d’informations sur l’utilisation de l’API REST, consultez la [Référence d’API Amazon Simple Storage Service](https://docs.aws.amazon.com/AmazonS3/latest/API/).
Enfin, il vaut la peine de prêter attention à DNS et de vérifier que les demandes sont réparties sur un vaste groupe d’adresses IP Amazon S3. Les requêtes DNS pour le Amazon S3 parcourent une large liste de points de terminaison IP. Mais la mise en cache des programmes de résolution ou du code d’application qui réutilise une seule adresse IP ne tire pas parti de la diversité des adresses et de l’équilibrage de charge qui en découle. Les outils d’utilitaire réseau comme l’outil de ligne de commande `netstat` peuvent afficher les adresses IP utilisées pour la communication avec Amazon S3 et nous fournissons des instructions sur les configurations DNS à utiliser. Pour plus d’informations sur ces directives, consultez [Envoi de demandes](https://docs.aws.amazon.com/AmazonS3/latest/API/MakingRequests.html) dans la *Référence des API Amazon S3*.
## Utilisation d’Amazon S3 Transfer Acceleration pour accélérer les transferts de données disparates géographiquement
[Configuration de transferts de fichiers rapides et sécurisés à l’aide d’Amazon S3 Transfer Acceleration](transfer-acceleration.md) est efficace pour réduire ou supprimer la latence provoquée par la distance géographique entre les clients dispersés géographiquement et une application régionale qui utilise Amazon S3. Transfer Acceleration utilise les emplacements périphériques répartis dans le monde entier CloudFront pour le transport des données. Le réseau AWS périphérique possède des points de présence dans plus de 50 sites. Aujourd'hui, il est utilisé pour distribuer du contenu via Amazon Route 53 CloudFront et pour fournir des réponses rapides aux requêtes DNS adressées à [Amazon Route 53](https://docs.aws.amazon.com/route53/index.html).
Le réseau périphérique aide également à accélérer les transferts de données dans et en dehors d’Amazon S3. Il convient parfaitement aux applications qui transfèrent les données entre les continents, ont une connexion Internet rapide, utilise des objets de grande taille ou ont un contenu volumineux à charger. Lorsque les données arrivent dans un emplacement périphérique, elles sont transférées vers Amazon S3 sur un chemin de réseau optimisé. En général, plus vous êtes loin d’une région Amazon S3, plus vous pouvez escompter une amélioration de la vitesse grâce à Transfer Acceleration.
Vous pouvez configurer Transfer Acceleration sur les compartiments nouveaux ou existants. Vous pouvez utiliser un point de terminaison Amazon S3 Transfer Acceleration distinct pour utiliser les emplacements AWS périphériques. Le meilleur moyen de tester si Transfer Acceleration améliore les performances des demandes des clients consiste à utiliser l’[Outil de comparaison de la vitesse de Amazon S3 Transfer Acceleration](https://s3-accelerate-speedtest.s3-accelerate.amazonaws.com/en/accelerate-speed-comparsion.html). Les configurations et les états du réseau varient de temps à autre et d’emplacement à emplacement. Par conséquent, vous n’êtes facturé que pour les transferts où Amazon S3 Transfer Acceleration peut potentiellement améliorer vos performances de chargement. Pour plus d'informations sur l'utilisation de Transfer Acceleration avec différents types AWS SDKs, consultez[Activation et utilisation de S3 Transfer Acceleration](transfer-acceleration-examples.md).
## Optimisation pour les charges de travail à taux de demandes élevés
Les applications qui génèrent des taux de demandes élevés pour Amazon S3 exigent des modèles de conception spécifiques pour obtenir des performances optimales. Lorsque votre application génère régulièrement plus de 3 500 PUT/COPY/POST/DELETE or 5,500 GET/HEAD requêtes par seconde et par préfixe, vous devez mettre en œuvre des stratégies pour distribuer les demandes et gérer le comportement de dimensionnement.
Amazon S3 se met automatiquement à l’échelle pour s’adapter à la hausse des taux de demandes, mais cette mise à l’échelle est progressive. Pendant ce processus, vous pouvez recevoir des réponses HTTP 503 (Ralentissement). Ces réponses sont temporaires et indiquent qu’Amazon S3 optimise ses systèmes internes pour s’adapter à votre nouveau modèle de demande. Une fois la mise à l’échelle terminée, vos demandes sont traitées sans limitation.
Pour optimiser les performances face aux charges de travail à taux de demandes élevés, envisagez les stratégies suivantes :
+ **Répartir les demandes entre plusieurs préfixes** : utilisez un modèle de préfixe randomisé ou séquentiel pour répartir les demandes sur plusieurs partitions. Par exemple, au lieu d’utiliser des noms d’objets séquentiels tels que `log-2024-01-01.txt`, utilisez des préfixes aléatoires comme `a1b2/log-2024-01-01.txt`. Amazon S3 peut ainsi répartir la charge plus efficacement.
+ **Implémenter un backoff exponentiel pour les erreurs 503** : lorsque vous recevez des réponses HTTP 503, implémentez une logique de nouvelle tentative avec un backoff exponentiel. Commencez par un délai court et augmentez progressivement le temps d’attente entre les tentatives. Ils AWS SDKs incluent une logique de nouvelle tentative intégrée qui gère cela automatiquement.
+ **Surveillez les modèles de demandes** : utilisez CloudWatch les statistiques Amazon pour surveiller vos taux de demandes et vos taux d'erreur. Portez une attention particulière aux métriques des erreurs 5xx, qui peuvent indiquer quand votre application approche ou dépasse les limites de mise à l’échelle en cours.
+ **Augmenter progressivement les taux de demandes :** lorsque vous lancez de nouvelles applications ou que vous augmentez significativement les taux de demandes, augmentez progressivement votre trafic au lieu de passer immédiatement à des taux de crête. Amazon S3 peut ainsi s’adapter de manière proactive et réduire le risque de limitation.
+ **Utiliser plusieurs connexions** : répartissez vos demandes sur plusieurs connexions HTTP afin d’optimiser le débit et de réduire l’impact des problèmes de connexion ponctuels.
Pour les applications qui ont besoin de performances élevées constantes, pensez à utiliser Amazon S3 Express One Zone, qui a été conçu pour les applications nécessitant des latences à un chiffre en millisecondes et peut prendre en charge des centaines de milliers de demandes par seconde. Pour de plus amples informations, veuillez consulter [S3 Express One Zone](directory-bucket-high-performance.md#s3-express-one-zone).