seaweedfs
3.80
SeaweedFS est un projet open source indépendant sous licence Apache dont le développement continu est entièrement rendu possible grâce au soutien de ces formidables bailleurs de fonds. Si vous souhaitez développer SeaweedFS encore plus fort, pensez à rejoindre nos sponsors sur Patreon.
Votre soutien sera vraiment apprécié par moi et par les autres supporters !
docker run -p 8333:8333 chrislusf/seaweedfs server -s3
weed ou weed.exe . Ou exécutez go install github.com/seaweedfs/seaweedfs/weed@latest .weed server -dir=/some/data/dir -s3 pour démarrer un maître, un serveur de volume, un filer et une passerelle S3. De plus, pour augmenter la capacité, ajoutez simplement plus de serveurs de volume en exécutant weed volume -dir="/some/data/dir2" -mserver="<master_host>:9333" -port=8081 localement, ou sur une autre machine, ou sur des milliers de machines. C'est ça !
SeaweedFS est un système de fichiers distribué simple et hautement évolutif. Il y a deux objectifs :
SeaweedFS a démarré en tant que magasin d'objets pour gérer efficacement les petits fichiers. Au lieu de gérer toutes les métadonnées des fichiers dans un maître central, le maître central gère uniquement les volumes sur les serveurs de volumes, et ces serveurs de volumes gèrent les fichiers et leurs métadonnées. Cela soulage la pression de concurrence du maître central et répartit les métadonnées des fichiers sur les serveurs de volume, permettant un accès plus rapide aux fichiers (O(1), généralement une seule opération de lecture sur disque).
Il n'y a que 40 octets de stockage sur disque pour les métadonnées de chaque fichier. C'est si simple avec les lectures de disque O(1) que vous pouvez défier les performances avec vos cas d'utilisation réels.
SeaweedFS a commencé par implémenter le document de conception Haystack de Facebook. De plus, SeaweedFS implémente le codage d'effacement avec les idées de f4 : le système de stockage Warm BLOB de Facebook, et présente de nombreuses similitudes avec le système de fichiers Tectonic de Facebook.
En plus du magasin d'objets, Filer facultatif peut prendre en charge les répertoires et les attributs POSIX. Filer est un serveur sans état distinct, évolutif de manière linéaire, avec des magasins de métadonnées personnalisables, par exemple MySql, Postgres, Redis, Cassandra, HBase, Mongodb, Elastic Search, LevelDB, RocksDB, Sqlite, MemSql, TiDB, Etcd, CockroachDB, YDB, etc.
Pour tous les magasins de valeurs de clés distribués, les grandes valeurs peuvent être déchargées vers SeaweedFS. Grâce à sa vitesse d'accès rapide et à sa capacité évolutive linéairement, SeaweedFS peut fonctionner comme un magasin distribué de clés de grande valeur.
SeaweedFS peut s'intégrer de manière transparente au cloud. Avec des données chaudes sur le cluster local et des données chaudes sur le cloud avec un temps d'accès O(1), SeaweedFS peut atteindre à la fois un temps d'accès local rapide et une capacité de stockage cloud élastique. De plus, le coût de l'API d'accès au stockage cloud est minimisé. Plus rapide et moins cher que le stockage cloud direct !
Retour à la table des matières
Retour à la table des matières
Retour à la table des matières
Par défaut, le nœud maître s'exécute sur le port 9333 et les nœuds de volume sur le port 8080. Démarrons un nœud maître et deux nœuds de volume sur les ports 8080 et 8081. Idéalement, ils devraient être démarrés à partir de machines différentes. Nous utiliserons localhost comme exemple.
SeaweedFS utilise les opérations HTTP REST pour lire, écrire et supprimer. Les réponses sont au format JSON ou JSONP.
> ./weed master
> weed volume -dir="/tmp/data1" -max=5 -mserver="localhost:9333" -port=8080 &
> weed volume -dir="/tmp/data2" -max=10 -mserver="localhost:9333" -port=8081 &
Pour télécharger un fichier : commencez par envoyer une requête HTTP POST, PUT ou GET à /dir/assign pour obtenir un fid et une URL de serveur de volume :
> curl http://localhost:9333/dir/assign
{"count":1,"fid":"3,01637037d6","url":"127.0.0.1:8080","publicUrl":"localhost:8080"}
Deuxièmement, pour stocker le contenu du fichier, envoyez une requête HTTP POST en plusieurs parties à url + '/' + fid à partir de la réponse :
> curl -F file=@/home/chris/myphoto.jpg http://127.0.0.1:8080/3,01637037d6
{"name":"myphoto.jpg","size":43234,"eTag":"1cc0118e"}
Pour mettre à jour, envoyez une autre requête POST avec le contenu du fichier mis à jour.
Pour la suppression, envoyez une requête HTTP DELETE à la même url + '/' + fid :
> curl -X DELETE http://127.0.0.1:8080/3,01637037d6
Maintenant, vous pouvez enregistrer le fid , 3,01637037d6 dans ce cas, dans un champ de base de données.
Le chiffre 3 au début représente un identifiant de volume. Après la virgule, il y a une clé de fichier, 01, et un cookie de fichier, 637037d6.
L'identifiant du volume est un entier non signé de 32 bits. La clé du fichier est un entier non signé de 64 bits. Le cookie de fichier est un entier non signé de 32 bits, utilisé pour empêcher la prédiction d'URL.
La clé du fichier et le cookie du fichier sont tous deux codés en hexadécimal. Vous pouvez stocker le tuple <volume id, file key, file cookie> dans votre propre format, ou simplement stocker le fid sous forme de chaîne.
S'il est stocké sous forme de chaîne, en théorie, vous auriez besoin de 8+1+16+8=33 octets. Un char(33) serait suffisant, sinon plus que suffisant, puisque la plupart des utilisations n'auront pas besoin de 2 ^ 32 volumes.
Si l'espace est vraiment un problème, vous pouvez stocker l'identifiant du fichier dans votre propre format. Vous auriez besoin d'un entier de 4 octets pour l'ID de volume, d'un numéro de 8 octets pour la clé de fichier et d'un entier de 4 octets pour le cookie de fichier. Donc 16 octets suffisent amplement.
Voici un exemple de la façon de rendre l'URL.
Recherchez d’abord les URL du serveur de volume à l’aide du volumeId du fichier :
> curl http://localhost:9333/dir/lookup?volumeId=3
{"volumeId":"3","locations":[{"publicUrl":"localhost:8080","url":"localhost:8080"}]}
Comme (généralement) il n'y a pas trop de serveurs de volumes et que les volumes ne bougent pas souvent, vous pouvez mettre les résultats en cache la plupart du temps. Selon le type de réplication, un volume peut avoir plusieurs emplacements de réplication. Choisissez simplement au hasard un endroit à lire.
Vous pouvez maintenant prendre l'URL publique, restituer l'URL ou lire directement depuis le serveur de volume via l'URL :
http://localhost:8080/3,01637037d6.jpg
Notez que nous ajoutons ici une extension de fichier ".jpg". C'est facultatif et ce n'est qu'un moyen pour le client de spécifier le type de contenu du fichier.
Si vous souhaitez une URL plus agréable, vous pouvez utiliser l'un de ces formats d'URL alternatifs :
http://localhost:8080/3/01637037d6/my_preferred_name.jpg
http://localhost:8080/3/01637037d6.jpg
http://localhost:8080/3,01637037d6.jpg
http://localhost:8080/3/01637037d6
http://localhost:8080/3,01637037d6
Si vous souhaitez obtenir une version à l'échelle d'une image, vous pouvez ajouter quelques paramètres :
http://localhost:8080/3/01637037d6.jpg?height=200&width=200
http://localhost:8080/3/01637037d6.jpg?height=200&width=200&mode=fit
http://localhost:8080/3/01637037d6.jpg?height=200&width=200&mode=fill
SeaweedFS applique la stratégie de réplication au niveau du volume. Ainsi, lorsque vous obtenez un identifiant de fichier, vous pouvez spécifier la stratégie de réplication. Par exemple:
curl http://localhost:9333/dir/assign?replication=001
Les options des paramètres de réplication sont :
000: no replication
001: replicate once on the same rack
010: replicate once on a different rack, but same data center
100: replicate once on a different data center
200: replicate twice on two different data center
110: replicate once on a different rack, and once on a different data center
Plus de détails sur la réplication peuvent être trouvés sur le wiki.
Vous pouvez également définir la stratégie de réplication par défaut lors du démarrage du serveur maître.
Les serveurs de volume peuvent être démarrés avec un nom de centre de données spécifique :
weed volume -dir=/tmp/1 -port=8080 -dataCenter=dc1
weed volume -dir=/tmp/2 -port=8081 -dataCenter=dc2
Lors de la demande d'une clé de fichier, un paramètre facultatif "dataCenter" peut limiter le volume attribué au centre de données spécifique. Par exemple, ceci spécifie que le volume attribué doit être limité à « dc1 » :
http://localhost:9333/dir/assign?dataCenter=dc1
Retour à la table des matières
Les systèmes de fichiers généralement distribués divisent chaque fichier en morceaux, un maître central conserve un mappage des noms de fichiers, des index de morceaux aux descripteurs de morceaux, ainsi que les morceaux dont dispose chaque serveur de morceaux.
Le principal inconvénient est que le maître central ne peut pas gérer efficacement de nombreux petits fichiers et que, comme toutes les demandes de lecture doivent passer par le maître de blocs, il peut ne pas s'adapter correctement à de nombreux utilisateurs simultanés.
Au lieu de gérer des morceaux, SeaweedFS gère les volumes de données sur le serveur maître. Chaque volume de données a une taille de 32 Go et peut contenir de nombreux fichiers. Et chaque nœud de stockage peut contenir de nombreux volumes de données. Ainsi, le nœud maître n'a besoin que de stocker les métadonnées sur les volumes, ce qui représente une quantité de données assez petite et généralement stable.
Les métadonnées réelles du fichier sont stockées dans chaque volume sur des serveurs de volumes. Étant donné que chaque serveur de volume gère uniquement les métadonnées des fichiers sur son propre disque, avec seulement 16 octets pour chaque fichier, tous les accès aux fichiers peuvent lire les métadonnées des fichiers uniquement à partir de la mémoire et ne nécessitent qu'une seule opération sur le disque pour lire réellement les données du fichier.
À titre de comparaison, considérons qu'une structure d'inode xfs sous Linux fait 536 octets.
L'architecture est assez simple. Les données réelles sont stockées dans des volumes sur des nœuds de stockage. Un serveur de volumes peut avoir plusieurs volumes et peut prendre en charge l'accès en lecture et en écriture avec une authentification de base.
Tous les volumes sont gérés par un serveur maître. Le serveur maître contient l'ID de volume et le mappage du serveur de volume. Il s’agit d’informations assez statiques et peuvent être facilement mises en cache.
À chaque demande d'écriture, le serveur maître génère également une clé de fichier, qui est un entier non signé croissant de 64 bits. Étant donné que les demandes d'écriture ne sont généralement pas aussi fréquentes que les demandes de lecture, un serveur maître devrait être capable de bien gérer la concurrence.
Lorsqu'un client envoie une demande d'écriture, le serveur maître renvoie (identifiant de volume, clé de fichier, cookie de fichier, URL du nœud de volume) pour le fichier. Le client contacte ensuite le nœud de volume et POST le contenu du fichier.
Lorsqu'un client a besoin de lire un fichier basé sur (ID de volume, clé de fichier, cookie de fichier), il demande au serveur maître par l'ID de volume (URL du nœud de volume, URL publique du nœud de volume) ou le récupère à partir d'un cache. Ensuite, le client peut OBTENIR le contenu, ou simplement afficher l'URL sur les pages Web et laisser les navigateurs récupérer le contenu.
Veuillez consulter l'exemple pour plus de détails sur le processus d'écriture-lecture.
Dans l'implémentation actuelle, chaque volume peut contenir 32 gibioctets (32 Go ou 8x2 ^ 32 octets). C'est parce que nous alignons le contenu sur 8 octets. Nous pouvons facilement augmenter ce chiffre à 64 Go, ou 128 Go, ou plus, en modifiant 2 lignes de code, au prix d'un espace de remplissage gaspillé en raison de l'alignement.
Il peut y avoir 4 gibioctets (4 Go ou 2 ^ 32 octets) de volumes. La taille totale du système est donc de 8 x 4 Go x 4 Go, soit 128 exbioctets (128 EiB ou 2 ^ 67 octets).
La taille de chaque fichier individuel est limitée à la taille du volume.
Toutes les méta-informations de fichiers stockées sur un serveur de volume sont lisibles à partir de la mémoire sans accès au disque. Chaque fichier ne prend qu'une entrée de carte de 16 octets de <clé 64 bits, décalage 32 bits, taille 32 bits>. Bien entendu, chaque entrée de carte a son propre coût d’espace pour la carte. Mais généralement, l’espace disque s’épuise avant la mémoire.
Les serveurs de volumes locaux sont beaucoup plus rapides, tandis que les stockages cloud ont une capacité élastique et sont en fait plus rentables s'ils ne sont pas utilisés souvent (généralement gratuits à télécharger, mais relativement coûteux à accéder). Avec la structure en ajout uniquement et le temps d'accès O(1), SeaweedFS peut tirer parti du stockage local et cloud en déchargeant les données chaudes vers le cloud.
Généralement, les données chaudes sont récentes et les données chaudes sont anciennes. SeaweedFS place les volumes nouvellement créés sur des serveurs locaux et télécharge éventuellement les anciens volumes sur le cloud. Si les anciennes données sont consultées moins souvent, cela vous donne littéralement une capacité illimitée avec des serveurs locaux limités, tout en restant rapide pour les nouvelles données.
Avec le temps d'accès O(1), le coût de latence du réseau est maintenu au minimum.
Si les données chaudes/chaudes sont divisées en 20/80, avec 20 serveurs, vous pouvez atteindre une capacité de stockage de 100 serveurs. Cela représente une économie de 80 % ! Vous pouvez également réutiliser les 80 serveurs pour stocker également de nouvelles données et obtenir un débit de stockage multiplié par 5.
Retour à la table des matières
La plupart des autres systèmes de fichiers distribués semblent plus compliqués que nécessaire.
SeaweedFS se veut rapide et simple, tant dans la configuration que dans le fonctionnement. Si vous ne comprenez pas comment cela fonctionne lorsque vous arrivez ici, nous avons échoué ! Veuillez soulever un problème si vous avez des questions ou mettre à jour ce fichier avec des clarifications.
SeaweedFS avance constamment. Idem avec d'autres systèmes. Ces comparaisons peuvent être rapidement obsolètes. S'il vous plaît, aidez-nous à les tenir à jour.
Retour à la table des matières
HDFS utilise l'approche chunk pour chaque fichier et est idéal pour stocker des fichiers volumineux.
SeaweedFS est idéal pour servir rapidement et simultanément des fichiers relativement petits.
SeaweedFS peut également stocker des fichiers très volumineux en les divisant en morceaux de données gérables et stocker les identifiants de fichier des morceaux de données dans un méta-morceau. Ceci est géré par l'outil « téléchargement/téléchargement de mauvaises herbes », et les serveurs maîtres ou de volume de mauvaises herbes en sont agnostiques.
Retour à la table des matières
Les architectures sont pour la plupart les mêmes. SeaweedFS vise à stocker et lire des fichiers rapidement, avec une architecture simple et plate. Les principales différences sont
| Système | Métadonnées de fichier | Contenu du fichier lu | POIX | API REST | Optimisé pour un grand nombre de petits fichiers |
|---|---|---|---|---|---|
| AlguesFS | ID de volume de recherche, pouvant être mis en cache | O(1) recherche de disque | Oui | Oui | |
| Classeur d'algues FS | Linéairement évolutif, personnalisable | O(1) recherche de disque | FUSIBLE | Oui | Oui |
| GlusterFS | hachage | FUSIBLE, NFS | |||
| Céph | hachage + règles | FUSIBLE | Oui | ||
| OrignalFS | en mémoire | FUSIBLE | Non | ||
| MinIO | méta-fichier séparé pour chaque fichier | Oui | Non |
Retour à la table des matières
GlusterFS stocke les fichiers, à la fois les répertoires et le contenu, dans des volumes configurables appelés « briques ».
GlusterFS hache le chemin et le nom de fichier en identifiants, les attribue aux volumes virtuels, puis les mappe aux « briques ».
Retour à la table des matières
MooseFS choisit de négliger le problème des petits fichiers. D'après le manuel moosefs 3.0, "même un petit fichier occupera 64 Ko plus 4 Ko de sommes de contrôle et 1 Ko pour l'en-tête", car il "a été initialement conçu pour conserver de grandes quantités (comme plusieurs milliers) de très gros fichiers"
MooseFS Master Server conserve toutes les métadonnées en mémoire. Même problème que le nœud de nom HDFS.
Retour à la table des matières
Ceph peut être configuré de manière similaire à SeaweedFS en tant que magasin de clés->blob. C'est beaucoup plus compliqué, avec la nécessité de supporter des couches par-dessus. Voici une comparaison plus détaillée
SeaweedFS dispose d'un groupe maître centralisé pour rechercher les volumes libres, tandis que Ceph utilise des serveurs de hachage et de métadonnées pour localiser ses objets. Avoir un maître centralisé facilite le codage et la gestion.
Ceph, comme SeaweedFS, est basé sur le magasin d'objets RADOS. Ceph est plutôt compliqué avec des critiques mitigées.
Ceph utilise le hachage CRUSH pour gérer automatiquement le placement des données, ce qui est efficace pour localiser les données. Mais les données doivent être placées selon l'algorithme CRUSH. Toute mauvaise configuration entraînerait une perte de données. Les changements de topologie, tels que l'ajout de nouveaux serveurs pour augmenter la capacité, entraîneront une migration de données avec un coût d'E/S élevé pour s'adapter à l'algorithme CRUSH. SeaweedFS place les données en les attribuant à n'importe quel volume inscriptible. Si l'écriture sur un volume échoue, choisissez simplement un autre volume à écrire. Ajouter plus de volumes est également aussi simple que possible.
SeaweedFS est optimisé pour les petits fichiers. Les petits fichiers sont stockés sous la forme d'un bloc continu de contenu, avec au maximum 8 octets inutilisés entre les fichiers. L'accès aux petits fichiers est une lecture sur disque O(1).
SeaweedFS Filer utilise des magasins prêts à l'emploi, tels que MySql, Postgres, Sqlite, Mongodb, Redis, Elastic Search, Cassandra, HBase, MemSql, TiDB, CockroachCB, Etcd, YDB, pour gérer les répertoires de fichiers. Ces magasins sont éprouvés, évolutifs et plus faciles à gérer.
| AlguesFS | comparable à Ceph | avantage |
|---|---|---|
| Maître | MDS | plus simple |
| Volume | OSD | optimisé pour les petits fichiers |
| Déclarant | Ceph FS | linéairement évolutif, personnalisable, O(1) ou O(logN) |
Retour à la table des matières
MinIO suit de près AWS S3 et est idéal pour tester l'API S3. Il a une bonne interface utilisateur, des politiques, des versions, etc. SeaweedFS essaie de rattraper son retard ici. Il est également possible de mettre MinIO comme passerelle devant SeaweedFS ultérieurement.
Les métadonnées MinIO se trouvent dans des fichiers simples. Chaque écriture de fichier entraînera des écritures supplémentaires dans le méta-fichier correspondant.
MinIO n'a pas d'optimisation pour beaucoup de petits fichiers. Les fichiers sont simplement stockés tels quels sur les disques locaux. En plus du métafichier et des fragments supplémentaires pour le codage d'effacement, cela ne fait qu'amplifier le problème LOSF.
MinIO dispose de plusieurs E/S disque pour lire un fichier. SeaweedFS a des lectures de disque O(1), même pour les fichiers codés avec effacement.
MinIO dispose d'un codage d'effacement à temps plein. SeaweedFS utilise la réplication sur les données chaudes pour une vitesse plus rapide et applique éventuellement un codage d'effacement sur les données chaudes.
MinIO ne prend pas en charge les API de type POSIX.
MinIO a des exigences spécifiques en matière d'agencement du stockage. Il n’est pas flexible d’ajuster la capacité. Dans SeaweedFS, démarrez simplement un serveur de volume pointant vers le maître. C'est tout.
C'est un projet super excitant ! Et nous avons besoin d’aide et de soutien !
Retour à la table des matières
Guide d'installation pour les utilisateurs qui ne sont pas familiers avec Golang
Étape 1 : installez Go sur votre machine et configurez l'environnement en suivant les instructions sur :
https://golang.org/doc/install
assurez-vous de définir votre $GOPATH
Étape 2 : consultez ce dépôt :
git clone https://github.com/seaweedfs/seaweedfs.gitÉtape 3 : téléchargez, compilez et installez le projet en exécutant la commande suivante
cd seaweedfs/weed && make install Une fois cela fait, vous retrouverez l'exécutable "weed" dans votre répertoire $GOPATH/bin
Retour à la table des matières
Lorsque vous testez les performances de lecture sur SeaweedFS, cela devient essentiellement un test de performances de la vitesse de lecture aléatoire de votre disque dur. Les disques durs obtiennent généralement 100 Mo/s à 200 Mo/s.
Pour modifier ou supprimer de petits fichiers, SSD doit supprimer un bloc entier à la fois et déplacer le contenu des blocs existants vers un nouveau bloc. Le SSD est rapide lorsqu'il est neuf, mais il se fragmentera avec le temps et vous devrez collecter les ordures et compacter les blocs. SeaweedFS est compatible avec les SSD car il s'agit uniquement d'ajouts. La suppression et le compactage sont effectués au niveau du volume en arrière-plan, sans ralentir la lecture ni provoquer de fragmentation.
Retour à la table des matières
Mes propres résultats non scientifiques sur une seule machine sur Mac Book avec disque SSD, processeur : 1 Intel Core i7 2,6 GHz.
Écrivez 1 million de fichiers de 1 Ko :
Concurrency Level: 16
Time taken for tests: 66.753 seconds
Completed requests: 1048576
Failed requests: 0
Total transferred: 1106789009 bytes
Requests per second: 15708.23 [#/sec]
Transfer rate: 16191.69 [Kbytes/sec]
Connection Times (ms)
min avg max std
Total: 0.3 1.0 84.3 0.9
Percentage of the requests served within a certain time (ms)
50% 0.8 ms
66% 1.0 ms
75% 1.1 ms
80% 1.2 ms
90% 1.4 ms
95% 1.7 ms
98% 2.1 ms
99% 2.6 ms
100% 84.3 ms
Lisez au hasard 1 million de fichiers :
Concurrency Level: 16
Time taken for tests: 22.301 seconds
Completed requests: 1048576
Failed requests: 0
Total transferred: 1106812873 bytes
Requests per second: 47019.38 [#/sec]
Transfer rate: 48467.57 [Kbytes/sec]
Connection Times (ms)
min avg max std
Total: 0.0 0.3 54.1 0.2
Percentage of the requests served within a certain time (ms)
50% 0.3 ms
90% 0.4 ms
98% 0.6 ms
99% 0.7 ms
100% 54.1 ms
make benchmark
warp: Benchmark data written to "warp-mixed-2023-10-16[102354]-l70a.csv.zst"
Mixed operations.
Operation: DELETE, 10%, Concurrency: 20, Ran 4m59s.
* Throughput: 6.19 obj/s
Operation: GET, 45%, Concurrency: 20, Ran 5m0s.
* Throughput: 279.85 MiB/s, 27.99 obj/s
Operation: PUT, 15%, Concurrency: 20, Ran 5m0s.
* Throughput: 89.86 MiB/s, 8.99 obj/s
Operation: STAT, 30%, Concurrency: 20, Ran 5m0s.
* Throughput: 18.63 obj/s
Cluster Total: 369.74 MiB/s, 61.79 obj/s, 0 errors over 5m0s.
Pour afficher les statistiques de requêtes segmentées, utilisez le paramètre --analyze.v.
warp analyze --analyze.v warp-mixed-2023-10-16[102354]-l70a.csv.zst
18642 operations loaded... Done!
Mixed operations.
----------------------------------------
Operation: DELETE - total: 1854, 10.0%, Concurrency: 20, Ran 5m0s, starting 2023-10-16 10:23:57.115 +0500 +05
* Throughput: 6.19 obj/s
Requests considered: 1855:
* Avg: 104ms, 50%: 30ms, 90%: 207ms, 99%: 1.355s, Fastest: 1ms, Slowest: 4.613s, StdDev: 320ms
----------------------------------------
Operation: GET - total: 8388, 45.3%, Size: 10485760 bytes. Concurrency: 20, Ran 5m0s, starting 2023-10-16 10:23:57.12 +0500 +05
* Throughput: 279.77 MiB/s, 27.98 obj/s
Requests considered: 8389:
* Avg: 221ms, 50%: 106ms, 90%: 492ms, 99%: 1.739s, Fastest: 8ms, Slowest: 8.633s, StdDev: 383ms
* TTFB: Avg: 81ms, Best: 2ms, 25th: 24ms, Median: 39ms, 75th: 65ms, 90th: 171ms, 99th: 669ms, Worst: 4.783s StdDev: 163ms
* First Access: Avg: 240ms, 50%: 105ms, 90%: 511ms, 99%: 2.08s, Fastest: 12ms, Slowest: 8.633s, StdDev: 480ms
* First Access TTFB: Avg: 88ms, Best: 2ms, 25th: 24ms, Median: 38ms, 75th: 64ms, 90th: 179ms, 99th: 919ms, Worst: 4.783s StdDev: 199ms
* Last Access: Avg: 219ms, 50%: 106ms, 90%: 463ms, 99%: 1.782s, Fastest: 9ms, Slowest: 8.633s, StdDev: 416ms
* Last Access TTFB: Avg: 81ms, Best: 2ms, 25th: 24ms, Median: 39ms, 75th: 65ms, 90th: 161ms, 99th: 657ms, Worst: 4.783s StdDev: 176ms
----------------------------------------
Operation: PUT - total: 2688, 14.5%, Size: 10485760 bytes. Concurrency: 20, Ran 5m0s, starting 2023-10-16 10:23:57.115 +0500 +05
* Throughput: 89.83 MiB/s, 8.98 obj/s
Requests considered: 2689:
* Avg: 1.165s, 50%: 878ms, 90%: 2.015s, 99%: 5.74s, Fastest: 99ms, Slowest: 8.264s, StdDev: 968ms
----------------------------------------
Operation: STAT - total: 5586, 30.2%, Concurrency: 20, Ran 5m0s, starting 2023-10-16 10:23:57.113 +0500 +05
* Throughput: 18.63 obj/s
Requests considered: 5587:
* Avg: 15ms, 50%: 11ms, 90%: 34ms, 99%: 80ms, Fastest: 0s, Slowest: 245ms, StdDev: 17ms
* First Access: Avg: 14ms, 50%: 10ms, 90%: 33ms, 99%: 69ms, Fastest: 0s, Slowest: 203ms, StdDev: 16ms
* Last Access: Avg: 15ms, 50%: 11ms, 90%: 34ms, 99%: 74ms, Fastest: 0s, Slowest: 203ms, StdDev: 17ms
Cluster Total: 369.64 MiB/s, 61.77 obj/s, 0 errors over 5m0s.
Total Errors:0.
Retour à la table des matières
Sous licence Apache, version 2.0 (la « Licence » ); vous ne pouvez pas utiliser ce fichier sauf en conformité avec la licence. Vous pouvez obtenir une copie de la licence à
http://www.apache.org/licenses/LICENSE-2.0
Sauf disposition contraire de la loi applicable ou accord écrit, le logiciel distribué sous la licence est distribué « EN L'ÉTAT », SANS GARANTIE OU CONDITION D'AUCUNE SORTE, expresse ou implicite. Consultez la licence pour connaître la langue spécifique régissant les autorisations et les limitations en vertu de la licence.
Le texte de cette page est disponible pour modification et réutilisation selon les termes de la licence Creative Commons Attribution-Sharealike 3.0 Unported et de la licence de documentation libre GNU (non versionnée, sans sections invariantes, textes de couverture ou textes de couverture arrière).
Retour à la table des matières
