--- title: "Object Storage - Optimiser les performances" description: "Ce guide vous présente différentes méthodes pour optimiser les performances de vos buckets Object Storage, notamment la recherche par plage d'octets, le multipart upload ainsi que d'autres méthodes" url: https://docs.ovhcloud.com/fr/guides/storage-and-backup/object-storage/s3-performance-optimization lang: fr lastUpdated: 2026-03-06 --- # Object Storage - Optimiser les performances ## Objectif Il existe plusieurs façons d'optimiser les performances de vos buckets sur l'Object Storage. **Le guide suivant vous présente les différentes méthodes d'optimisation.** ### Utilisation de la recherche par plage d'octets OVHcloud Object Storage prend en charge l'extraction de plage d'octets. L'idée est de récupérer un objet morceau par morceau, chaque morceau étant défini par une plage d'octets. Le principal avantage est qu'il vous permet de paralléliser les requêtes `GET` pour télécharger un objet, chaque requête `GET` demandant une plage d'octets spécifique : les tailles typiques des requêtes de plage d'octets sont de 8 Mo ou 16 Mo, mais vous pouvez spécifier n'importe quelle taille. ![Schema 1](/images/storage-and-backup/object-storage/s3-performance-optimization/sharding1.png) Pour télécharger une partie d'un objet, vous devez utiliser des paramètres supplémentaires pour spécifier la partie de l'objet à récupérer. L'exemple suivant télécharge la première partie, comprise entre 0 et 500 octets, d'un objet nommé `` stocké dans le bucket `` et écrit la sortie dans un fichier nommé `object_part` : ```bash aws s3api get-object --bucket --key --range bytes=0-500 object_part ``` ### Utilisation des MPU Vous pouvez télécharger un objet unique sous la forme d'une collection d'articles à l'aide des téléversements en plusieurs parties (_multipart uploads_). Ces parties peuvent être téléchargées séparément et dans n'importe quelle séquence. Vous pouvez retransmettre une pièce sans affecter les autres en cas d'échec de la transmission d'une pièce. Une fois toutes les pièces téléchargées, OVHcloud Object Storage les assemble et reconstruit l'objet. :::tip Pensez à utiliser des téléversements en plusieurs parties (_multipart uploads_) pour les objets > 100MB ::: Les avantages des \*multipart uploads- sont les suivants : - Débit accru : chaque partie peut être uploadée simultanément. - Récupération rapide en cas de problème réseau : chaque partie pouvant être uploadée séparément et indépendamment, vous pouvez re-uploader la partie manquante sans redémarrer l'upload complet. ## En pratique ### Via AWS CLI Vous aurez besoin des éléments suivants : - Avoir créé un [bucket OVHcloud](/fr/guides/storage-and-backup/object-storage/s3-getting-started-with-object-storage.md) - Avoir installé et configuré [AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html) - Avoir un fichier volumineux divisé en plusieurs parties :::info **Le saviez-vous ?** Lorsque vous utilisez une commande de haut niveau pour uploader un objet à l'aide de la commande `cp`, AWS CLI effectue automatiquement un _multipart upload_. Pour optimiser les valeurs de configuration par défaut pour les \*multipart uploads- (multipart\_threshold, multipart\_chunksize), vous pouvez consulter [cet article](/fr/guides/storage-and-backup/object-storage/s3-getting-started-with-object-storage.md) et voir le tableau expliquant comment configurer AWS CLI. ::: La section suivante explique comment effectuer un _multipart upload_\* à l'aide des commandes de bas niveau du AWS CLI. Tout d'abord, vous devez lancer un _multipart upload_\* : ```bash aws s3api create-multipart-upload --bucket `` --key `` { "Bucket": "``", "Key": "``", "UploadId": "``" } ``` :::info N'oubliez pas de sauvegarder les **upload ID**, **key** et **bucket name** pour les utiliser avec la commande `upload-part`. ::: Pour chaque partie, vous devez exécuter la commande `upload-part` dans laquelle vous spécifiez les _bucket_, \*key- et \*upload ID- : :::warning Les numéros de référence peuvent être compris entre 1 et 10 000 inclus. Vous pouvez vérifier les limitations techniques [ici](/fr/guides/storage-and-backup/object-storage/s3-limitations.md). ::: ```bash aws s3api upload-part --bucket --key --part-number 1 --body --upload-id { "ETag": "\"6769849e543eeb257675b65e7a199aa2\"" } ``` :::info Enregistrez la valeur \*_ETag_- de chaque article pour plus tard. Elles sont nécessaires pour terminer le _multipart upload_. ::: Une fois toutes les pièces téléchargées, vous devez exécuter la commande `complete-multipart-upload` pour terminer le processus et pour que le OVHcloud Object Storage reconstruise l'objet final : ```bash aws s3api complete-multipart-upload --bucket `` --key --upload-id `` --multipart-upload file://mpu.json ``` Où `mpu.json` est : ```json { "Parts": [ { "ETag": "6769849e543eeb257675b65e7a199aa2", "PartNumber": 1 }, { "ETag": "3617fbc52bcc2cc8a6cbfe81457c01c4", "PartNumber": 2 }, { "ETag": "4f8c06e93b407f1f2d6fb1614d73906d", "PartNumber": 3 }, { "ETag": "739213d60193c2154e74cc9895f17132", "PartNumber": 4 }, { "ETag": "f7551c4f2eef8b4f431ea9b89a106e66", "PartNumber": 5 }, { "ETag": "d1ee8ef1735cc647537dc27745a4d78f", "PartNumber": 6 }, { "ETag": "083560bc5d313203969979347e530816", "PartNumber": 7 }, { "ETag": "14614d7b76b64e455c8e53661067e2c8", "PartNumber": 8 }, { "ETag": "aa9bcb39247074216c7e26f90b21a71b", "PartNumber": 9 }, { "ETag": "9617fc9e0efb944fa3e4ba970b3ebe62", "PartNumber": 10 } ] } ``` :::info Si le _multipart upload_ n'est pas terminé, l'objet final ne sera pas assemblé et restera invisible. Néanmoins, toutes les pièces téléchargées restent stockées et entraînent des frais de stockage. ::: Pour éviter des coûts inutiles, vous pouvez interrompre le _multipart upload_ à l'aide de la commande CLI AWS suivante : ```bash aws s3api abort-multipart-upload \ --bucket \ --key \ --upload-id ``` L'ID de l'upload est renvoyé par la commande `create-multipart-upload` ou peut être récupéré en listant les _multipart uploads_ en cours : ```bash aws s3api list-multipart-uploads --bucket `` ``` Exemple d'interruption d'un _multipart upload_ spécifique après avoir récupéré son ID d'upload : ```bash aws s3api abort-multipart-upload \ --bucket `` \ --upload-id `` \ --key `` ``` ### Via d'autres outils tiers La liste suivante décrit les options permettant d'effectuer des _multipart uploads_\* à l'aide d'autres outils. La liste n'est pas exhaustive car vous pouvez également vérifier la documentation appropriée pour l'outil que vous utilisez. #### s3cmd ```bash multipart-chunk-size-mb=`` ``` Cette commande représente la taille de chaque segment d'un _multipart upload_ . Les fichiers supérieurs à SIZE sont automatiquement téléchargés en tant que fichiers multithread-multipart.Les fichiers plus petits sont téléchargés à l'aide de la méthode traditionnelle. SIZE est exprimé en méga-octets, la taille de bloc par défaut est de 15 Mo, la taille de bloc minimale autorisée est de 5 Mo, la taille maximale est de 5 Go. Exemple : ```bash s3cmd put --multipart-chunk-size-mb=500 `` s3://``/ ``` Pour plus d'informations sur _s3cmd_, consultez la documentation officielle [ici](https://s3tools.org/usage). #### rclone ```bash s3-upload-cutoff=`` ``` Cette commande représente le seuil de taille à partir duquel rclone passe d'un upload d'un fichier unique au _multipart upload_. ```bash s3-chunk-size=`` ``` Cette commande représente la taille de chaque segment utilisé dans les _multipart uploads_. ```bash s3-upload-concurrency=`` ``` Cette commande représente le nombre de segments uploadés simultanément. Exemple : ```bash rclone copy --s3-upload-concurrency 300 --s3-chunk-size 100M --s3-upload-cutoff 100M `` s3:`` ``` Pour plus d'informations sur _rclone_, consultez la [documentation officielle](https://rclone.org/s3/). ### Augmentation du nombre de demandes simultanées Une autre façon d'améliorer le débit est d'augmenter le nombre de demandes simultanées. Pour personnaliser la valeur par défaut sur AWS CLI, consultez [ce guide](/fr/guides/storage-and-backup/object-storage/s3-optimise-the-sending-of-your-files.md). Pour les autres outils, nous vous invitons à consulter la documentation du logiciel utilisé. ### Optimisation I/O Il est également possible d’optimiser considérablement les performances en adoptant de bonnes pratiques pour répartir les I/O le plus largement possible dans le cluster de stockage d’objets, en tirant parti du mécanisme de fragmentation (_sharding_). \*_Qu’est-ce que le _sharding- ?__ OpenIO est une solution de _Software-Defined Storage_ sur laquelle repose l’Object Storage d’OVHcloud. Dans OpenIO, un \*_conteneur_- est essentiellement une entité logique interne qui contient tous les objets d'un bucket donné. Chaque conteneur est associé à une base de données de métadonnées interne qui répertorie toutes les adresses du cluster des objets qu'il contient. Par défaut, un bucket Object Storage est associé à un conteneur, mais cela peut changer avec le mécanisme de _sharding_. Le _sharding_ est le mécanisme par lequel un conteneur est divisé en 2 nouveaux sous-conteneurs (et donc sa base de données de métadonnées associée est également divisée en 2) lorsqu'il atteint **un nombre critique d'objets** appelé **shards**. Le \*sharding- permet : - d'optimiser les opérations de lecture/écriture en les répartissant uniformément sur plusieurs serveurs (_shards_). - de répartir le stockage des données sur l'ensemble du cluster pour augmenter la résilience. Nous utilisons les clés d'objet (préfixe/nom) pour déterminer quels objets sont poussés dans quel sous-conteneur en utilisant la logique suivante : - Créer 2 nouveaux _shards_. - Recherche la valeur médiane d'une liste de toutes les clés d'objet triées par ordre alphabétique. - Copier le contenu du conteneur racine dans les _shards_. - Dans le premier _shard_, ne conserver que la première moitié des objets (de l'objet avec la première clé de la liste à l'objet avec une clé égale à la valeur médiane) et nettoyer la seconde moitié. - Dans le second _shard_, ne conserver que la seconde moitié des objets et nettoyer la première moitié. - Le conteneur racine ne liste alors que les références aux shards, c'est-à-dire quelle plage d'objets dans quel _shard_. Cette logique peut se résumer ainsi : ![Schema 2](/images/storage-and-backup/object-storage/s3-performance-optimization/sharding2.png) ### Les bonnes pratiques du préfixe Vous pouvez optimiser les I/O sur le cluster en profitant des mécanismes de _sharding_ décrits ci-dessus. La stratégie principale est de garder la cardinalité des clés d'objet à gauche, c'est-à-dire d'utiliser des préfixes qui permettent au _sharding_ de diviser les objets entrants aussi uniformément que possible. Considérons un cas d'utilisation où vous souhaiteriez stocker des logs dans un Object Storage OVHcloud. #### Scénario 1 - Mauvaise pratique en utilisant la date comme préfixe Liste des objets : - 20240216/file01.log - 20240216/file02.log - 20240216/file03.log - ... - 20240217/file01.log - 20240217/file02.log - ... En supposant un seuil de 100, après le téléchargement du 100ème objet, le _sharding_ est déclenché pour diviser les objets en deux fragments : - de 20240216/file01.log à 20240216/file100.log dans le premier _shard_ - à partir de 20240216/file101.log et au-delà vers un second _shard_ Cette solution n'est pas optimale car, les dates étant par nature incrémentales, tous les nouveaux téléchargements seront toujours effectués sur le second _shard_, qui sera à nouveau fractionné lorsqu'il atteindra une taille critique. Ainsi, toutes les opérations d'écriture futures seront toujours effectuées sur le dernier _shard_ créé et les _shards_ précédents seront rarement utilisés. En outre, vous pouvez rencontrer une certaine limitation pendant le processus de _sharding_. ![Schema 3](/images/storage-and-backup/object-storage/s3-performance-optimization/sharding3.png) #### Scénario 2 - Bonne pratique pour maintenir la cardinalité à droite Liste des objets : - server/apache/file20240216.log - server/apache/file20240217.log - server/apache/file20240218.log - ... - db/mongodb/file20240216.log - db/mongodb/file20240217.log - ... En supposant un seuil de 100, après le téléchargement du 100ème objet, le _sharding_ est déclenché pour fractionner les objets en 2 _shards_. Ce deuxième scénario est optimal car tous les nouveaux uploads seront répartis sur les 2 _shards_. ![Schema 4](/images/storage-and-backup/object-storage/s3-performance-optimization/sharding4.png) ### Optimiser le temps de montée en charge Lorsque vous chargez un très grand nombre d'objets à la fois, vous déclenchez le mécanisme de fragmentation (_sharding_). Au cours du processus de fragmentation, vous pouvez rencontrer une certaine limitation. Afin d'éviter la baisse de performance (erreurs 503 SLOWDOWN), nous vous recommandons d'optimiser vos uploads en étalant votre requête dans le temps. Cet écart n'a pas à être linéaire, mais il doit nous donner suffisamment de temps pour équilibrer votre charge de travail. Un moyen simple d'y parvenir consiste à améliorer la gestion des erreurs 503 SLOWDOWN et la récupération des erreurs : augmentez vos uploads jusqu'à ce que vous atteigniez des erreyrs 503 et modulez votre charge de travail pour accommoder la limitation jusqu'à ce que le _sharding_ soit terminé, puis augmentez à nouveau. ### Augmenter la taille des objets Les objets sont considérés comme petits s'ils ont une taille inférieure à 1 Mo. Lorsqu'il s'agit de grands volumes de données (à l'échelle du Po), le nombre total d'objets atteint rapidement des milliards, voire des trillions. Gérer l’administration des métadonnées à cette échelle et le nombre d’opérations d’I/O représente un défi majeur : comment fournir un service de qualité sans perdre d’informations ni compromettre les performances ?. Le cas échéant, nous vous recommandons d'augmenter autant que possible la taille de l'objet/de la pièce afin de réduire le nombre d'objets. ## Aller plus loin [](#) Si vous avez besoin d'une formation ou d'une assistance technique pour la mise en oeuvre de nos solutions, contactez votre commercial ou cliquez sur [ce lien](https://www.ovhcloud.com/fr/professional-services/) pour obtenir un devis et demander une analyse personnalisée de votre projet à nos experts de l’équipe Professional Services. Échangez avec notre [communauté d’utilisateurs](https://community.ovhcloud.com/).