seaweedfs
3.80
SeaweedFS é um projeto independente de código aberto licenciado pelo Apache, com seu desenvolvimento contínuo tornado possível inteiramente graças ao apoio desses patrocinadores incríveis. Se você gostaria de deixar o SeaweedFS ainda mais forte, considere juntar-se aos nossos patrocinadores no Patreon.
Seu apoio será muito apreciado por mim e por outros apoiadores!
docker run -p 8333:8333 chrislusf/seaweedfs server -s3
weed ou weed.exe . Ou execute go install github.com/seaweedfs/seaweedfs/weed@latest .weed server -dir=/some/data/dir -s3 para iniciar um mestre, um servidor de volume, um arquivador e um gateway S3. Além disso, para aumentar a capacidade, basta adicionar mais servidores de volume executando weed volume -dir="/some/data/dir2" -mserver="<master_host>:9333" -port=8081 localmente, ou em uma máquina diferente, ou em milhares de máquinas. É isso!
SeaweedFS é um sistema de arquivos distribuído simples e altamente escalável. Existem dois objetivos:
SeaweedFS começou como um Object Store para lidar com arquivos pequenos com eficiência. Em vez de gerenciar todos os metadados de arquivos em um mestre central, o mestre central gerencia apenas volumes em servidores de volume, e esses servidores de volume gerenciam arquivos e seus metadados. Isso alivia a pressão de simultaneidade do mestre central e espalha os metadados dos arquivos nos servidores de volume, permitindo acesso mais rápido aos arquivos (O(1), geralmente apenas uma operação de leitura de disco).
Há apenas 40 bytes de sobrecarga de armazenamento em disco para os metadados de cada arquivo. É tão simples com leituras de disco O(1) que você pode desafiar o desempenho com seus casos de uso reais.
SeaweedFS começou implementando o documento de design Haystack do Facebook. Além disso, SeaweedFS implementa codificação de eliminação com ideias de f4: Warm BLOB Storage System do Facebook e tem muitas semelhanças com o Tectonic Filesystem do Facebook
Além do armazenamento de objetos, o Filer opcional pode suportar diretórios e atributos POSIX. Filer é um servidor sem estado separado, linearmente escalável, com armazenamentos de metadados personalizáveis, por exemplo, MySql, Postgres, Redis, Cassandra, HBase, Mongodb, Elastic Search, LevelDB, RocksDB, Sqlite, MemSql, TiDB, Etcd, CockroachDB, YDB, etc.
Para quaisquer armazenamentos de valores-chave distribuídos, os valores grandes podem ser transferidos para o SeaweedFS. Com velocidade de acesso rápida e capacidade linearmente escalonável, o SeaweedFS pode funcionar como um armazenamento distribuído de grandes valores.
SeaweedFS pode ser integrado de forma transparente com a nuvem. Com dados quentes em cluster local e dados quentes na nuvem com tempo de acesso O(1), o SeaweedFS pode atingir tempo de acesso local rápido e capacidade elástica de armazenamento em nuvem. Além do mais, o custo da API de acesso ao armazenamento em nuvem é minimizado. Mais rápido e barato que o armazenamento direto na nuvem!
Voltar ao sumário
Voltar ao sumário
Voltar ao sumário
Por padrão, o nó mestre é executado na porta 9333 e os nós de volume são executados na porta 8080. Vamos iniciar um nó mestre e dois nós de volume nas portas 8080 e 8081. Idealmente, eles devem ser iniciados em máquinas diferentes. Usaremos localhost como exemplo.
SeaweedFS usa operações HTTP REST para ler, gravar e excluir. As respostas estão no formato 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 &
Para fazer upload de um arquivo: primeiro, envie uma solicitação HTTP POST, PUT ou GET para /dir/assign para obter um fid e um URL do servidor de volume:
> curl http://localhost:9333/dir/assign
{"count":1,"fid":"3,01637037d6","url":"127.0.0.1:8080","publicUrl":"localhost:8080"}
Segundo, para armazenar o conteúdo do arquivo, envie uma solicitação HTTP POST de várias partes para url + '/' + fid da resposta:
> curl -F file=@/home/chris/myphoto.jpg http://127.0.0.1:8080/3,01637037d6
{"name":"myphoto.jpg","size":43234,"eTag":"1cc0118e"}
Para atualizar, envie outra solicitação POST com o conteúdo do arquivo atualizado.
Para exclusão, envie uma solicitação HTTP DELETE para o mesmo url + '/' + fid :
> curl -X DELETE http://127.0.0.1:8080/3,01637037d6
Agora você pode salvar o fid 3,01637037d6 neste caso, em um campo do banco de dados.
O número 3 no início representa um ID de volume. Após a vírgula, há uma chave de arquivo, 01, e um cookie de arquivo, 637037d6.
O ID do volume é um número inteiro não assinado de 32 bits. A chave do arquivo é um número inteiro não assinado de 64 bits. O cookie do arquivo é um número inteiro não assinado de 32 bits, usado para evitar adivinhação de URL.
A chave do arquivo e o cookie do arquivo são codificados em hexadecimal. Você pode armazenar a tupla <volume id, file key, file cookie> em seu próprio formato ou simplesmente armazenar o fid como uma string.
Se armazenado como uma string, em teoria, você precisaria de 8+1+16+8=33 bytes. Um char(33) seria suficiente, se não mais que suficiente, já que a maioria dos usos não precisará de 2^32 volumes.
Se o espaço for realmente uma preocupação, você poderá armazenar o ID do arquivo em seu próprio formato. Você precisaria de um número inteiro de 4 bytes para o ID do volume, um número longo de 8 bytes para a chave do arquivo e um número inteiro de 4 bytes para o cookie do arquivo. Portanto, 16 bytes são mais que suficientes.
Aqui está um exemplo de como renderizar o URL.
Primeiro procure os URLs do servidor de volume pelo volumeId do arquivo:
> curl http://localhost:9333/dir/lookup?volumeId=3
{"volumeId":"3","locations":[{"publicUrl":"localhost:8080","url":"localhost:8080"}]}
Como (normalmente) não há muitos servidores de volume e os volumes não são movidos com frequência, você pode armazenar os resultados em cache na maior parte do tempo. Dependendo do tipo de replicação, um volume pode ter vários locais de réplica. Basta escolher aleatoriamente um local para ler.
Agora você pode pegar a URL pública, renderizá-la ou ler diretamente do servidor de volume via URL:
http://localhost:8080/3,01637037d6.jpg
Observe que adicionamos uma extensão de arquivo “.jpg” aqui. É opcional e apenas uma maneira de o cliente especificar o tipo de conteúdo do arquivo.
Se quiser um URL melhor, você pode usar um destes formatos de URL alternativos:
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
Se quiser obter uma versão em escala de uma imagem, você pode adicionar alguns parâmetros:
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 aplica a estratégia de replicação em nível de volume. Portanto, ao obter um ID de arquivo, você pode especificar a estratégia de replicação. Por exemplo:
curl http://localhost:9333/dir/assign?replication=001
As opções de parâmetro de replicação são:
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
Mais detalhes sobre replicação podem ser encontrados no wiki.
Você também pode definir a estratégia de replicação padrão ao iniciar o servidor mestre.
Os servidores de volume podem ser iniciados com um nome de data center específico:
weed volume -dir=/tmp/1 -port=8080 -dataCenter=dc1
weed volume -dir=/tmp/2 -port=8081 -dataCenter=dc2
Ao solicitar uma chave de arquivo, um parâmetro opcional "dataCenter" pode limitar o volume atribuído ao data center específico. Por exemplo, especifica que o volume atribuído deve ser limitado a 'dc1':
http://localhost:9333/dir/assign?dataCenter=dc1
Voltar ao sumário
Normalmente, os sistemas de arquivos distribuídos dividem cada arquivo em pedaços, um mestre central mantém um mapeamento de nomes de arquivos, índices de pedaços para identificadores de pedaços e também quais pedaços cada servidor de pedaços possui.
A principal desvantagem é que o master central não consegue lidar com muitos arquivos pequenos com eficiência e, como todas as solicitações de leitura precisam passar pelo chunk master, ele pode não ser bem dimensionado para muitos usuários simultâneos.
Em vez de gerenciar pedaços, o SeaweedFS gerencia volumes de dados no servidor mestre. Cada volume de dados tem 32 GB e pode conter muitos arquivos. E cada nó de armazenamento pode ter muitos volumes de dados. Portanto, o nó mestre só precisa armazenar os metadados sobre os volumes, o que representa uma quantidade bastante pequena de dados e geralmente estável.
Os metadados reais do arquivo são armazenados em cada volume nos servidores de volume. Como cada servidor de volume gerencia apenas metadados de arquivos em seu próprio disco, com apenas 16 bytes para cada arquivo, todos os acessos a arquivos podem ler metadados de arquivos apenas da memória e precisam apenas de uma operação de disco para realmente ler os dados do arquivo.
Para efeito de comparação, considere que uma estrutura de inode xfs no Linux tem 536 bytes.
A arquitetura é bastante simples. Os dados reais são armazenados em volumes em nós de armazenamento. Um servidor de volume pode ter vários volumes e pode suportar acesso de leitura e gravação com autenticação básica.
Todos os volumes são gerenciados por um servidor mestre. O servidor mestre contém o ID do volume para o mapeamento do servidor de volume. Esta é uma informação bastante estática e pode ser facilmente armazenada em cache.
Em cada solicitação de gravação, o servidor mestre também gera uma chave de arquivo, que é um número inteiro não assinado crescente de 64 bits. Como as solicitações de gravação geralmente não são tão frequentes quanto as solicitações de leitura, um servidor mestre deve ser capaz de lidar bem com a simultaneidade.
Quando um cliente envia uma solicitação de gravação, o servidor mestre retorna (id do volume, chave do arquivo, cookie do arquivo, URL do nó do volume) para o arquivo. O cliente então contata o nó do volume e envia o conteúdo do arquivo por POST.
Quando um cliente precisa ler um arquivo com base em (ID do volume, chave do arquivo, cookie do arquivo), ele solicita ao servidor mestre pelo ID do volume (URL do nó de volume, URL público do nó de volume) ou recupera-o de um cache. Em seguida, o cliente pode OBTER o conteúdo ou apenas renderizar a URL nas páginas da web e permitir que os navegadores busquem o conteúdo.
Consulte o exemplo para obter detalhes sobre o processo de gravação e leitura.
Na implementação atual, cada volume pode conter 32 gibibytes (32GiB ou 8x2^32 bytes). Isso ocorre porque alinhamos o conteúdo em 8 bytes. Podemos facilmente aumentar isso para 64GiB, ou 128GiB, ou mais, alterando 2 linhas de código, ao custo de algum desperdício de espaço de preenchimento devido ao alinhamento.
Pode haver 4 gibibytes (4GiB ou 2^32 bytes) de volumes. Portanto, o tamanho total do sistema é 8 x 4GiB x 4GiB, que é 128 exbibytes (128EiB ou 2 ^ 67 bytes).
Cada tamanho de arquivo individual é limitado ao tamanho do volume.
Todas as metainformações de arquivos armazenadas em um servidor de volume podem ser lidas na memória sem acesso ao disco. Cada arquivo leva apenas uma entrada de mapa de 16 bytes de <chave de 64 bits, deslocamento de 32 bits, tamanho de 32 bits>. É claro que cada entrada do mapa tem seu próprio custo de espaço no mapa. Mas geralmente o espaço em disco acaba antes da memória.
Os servidores de volume local são muito mais rápidos, enquanto os armazenamentos em nuvem têm capacidade elástica e são, na verdade, mais econômicos se não forem acessados com frequência (geralmente gratuitos para upload, mas relativamente caros para acesso). Com a estrutura somente anexada e o tempo de acesso O(1), o SeaweedFS pode aproveitar as vantagens do armazenamento local e na nuvem, descarregando os dados quentes para a nuvem.
Normalmente, os dados quentes são recentes e os dados quentes são antigos. SeaweedFS coloca os volumes recém-criados em servidores locais e, opcionalmente, carrega os volumes mais antigos na nuvem. Se os dados mais antigos forem acessados com menos frequência, isso literalmente lhe dará capacidade ilimitada com servidores locais limitados e ainda rápida para novos dados.
Com o tempo de acesso O(1), o custo de latência da rede é mantido no mínimo.
Se os dados quentes/quentes forem divididos em 20/80, com 20 servidores, você poderá atingir a capacidade de armazenamento de 100 servidores. Isso representa uma economia de custos de 80%! Ou você pode redirecionar os 80 servidores para armazenar novos dados também e obter uma taxa de transferência de armazenamento 5X maior.
Voltar ao sumário
A maioria dos outros sistemas de arquivos distribuídos parece mais complicada do que o necessário.
SeaweedFS foi criado para ser rápido e simples, tanto na configuração quanto na operação. Se você não entende como funciona quando chega aqui, falhamos! Levante um problema com qualquer dúvida ou atualize este arquivo com esclarecimentos.
SeaweedFS está constantemente avançando. O mesmo acontece com outros sistemas. Essas comparações podem ficar desatualizadas rapidamente. Por favor, ajude a mantê-los atualizados.
Voltar ao sumário
O HDFS usa a abordagem chunk para cada arquivo e é ideal para armazenar arquivos grandes.
SeaweedFS é ideal para servir arquivos relativamente menores de forma rápida e simultânea.
O SeaweedFS também pode armazenar arquivos extragrandes, dividindo-os em blocos de dados gerenciáveis e armazenando os IDs dos arquivos dos blocos de dados em um meta-bloco. Isso é gerenciado pela ferramenta "upload/download de ervas daninhas", e o mestre de ervas daninhas ou os servidores de volume são agnósticos sobre isso.
Voltar ao sumário
As arquiteturas são basicamente as mesmas. SeaweedFS tem como objetivo armazenar e ler arquivos de forma rápida, com uma arquitetura simples e plana. As principais diferenças são
| Sistema | Metadados de arquivo | Leitura do conteúdo do arquivo | POSIX | API REST | Otimizado para grande número de arquivos pequenos |
|---|---|---|---|---|---|
| Algas MarinhasFS | ID do volume de pesquisa, armazenável em cache | O (1) busca de disco | Sim | Sim | |
| Arquivador de algas marinhas FS | Linearmente escalável, personalizável | O (1) busca de disco | FUSÍVEL | Sim | Sim |
| GlusterFS | hash | FUSÍVEL, NFS | |||
| Ceph | hash + regras | FUSÍVEL | Sim | ||
| MooseFS | na memória | FUSÍVEL | Não | ||
| MinIO | meta-arquivo separado para cada arquivo | Sim | Não |
Voltar ao sumário
GlusterFS armazena arquivos, tanto diretórios quanto conteúdo, em volumes configuráveis chamados “tijolos”.
GlusterFS faz o hash do caminho e do nome do arquivo em ids, é atribuído a volumes virtuais e depois mapeado para "tijolos".
Voltar ao sumário
MooseFS opta por negligenciar problemas de arquivos pequenos. Do manual do moosefs 3.0, "mesmo um arquivo pequeno ocupará 64 KB, além de 4 KB de somas de verificação e 1 KB para o cabeçalho", porque "foi inicialmente projetado para manter grandes quantidades (como vários milhares) de arquivos muito grandes"
MooseFS Master Server mantém todos os metadados na memória. O mesmo problema do namenode HDFS.
Voltar ao sumário
O Ceph pode ser configurado de forma semelhante ao SeaweedFS como um armazenamento de chave-> blob. É muito mais complicado, com a necessidade de suportar camadas por cima. Aqui está uma comparação mais detalhada
SeaweedFS possui um grupo mestre centralizado para pesquisar volumes livres, enquanto Ceph usa servidores de hashing e metadados para localizar seus objetos. Ter um mestre centralizado facilita a codificação e o gerenciamento.
O Ceph, assim como o SeaweedFS, é baseado no armazenamento de objetos RADOS. Ceph é bastante complicado com análises mistas.
O Ceph usa hashing CRUSH para gerenciar automaticamente o posicionamento dos dados, o que é eficiente para localizar os dados. Mas os dados devem ser colocados de acordo com o algoritmo CRUSH. Qualquer configuração errada causaria perda de dados. Mudanças na topologia, como a adição de novos servidores para aumentar a capacidade, causarão migração de dados com alto custo de IO para se adequar ao algoritmo CRUSH. SeaweedFS coloca dados atribuindo-os a quaisquer volumes graváveis. Se a gravação em um volume falhar, basta escolher outro volume para gravar. Adicionar mais volumes também é tão simples quanto possível.
SeaweedFS é otimizado para arquivos pequenos. Arquivos pequenos são armazenados como um bloco contínuo de conteúdo, com no máximo 8 bytes não utilizados entre os arquivos. O acesso a arquivos pequenos é uma leitura de disco O(1).
SeaweedFS Filer usa lojas prontas para uso, como MySql, Postgres, Sqlite, Mongodb, Redis, Elastic Search, Cassandra, HBase, MemSql, TiDB, CockroachCB, Etcd, YDB, para gerenciar diretórios de arquivos. Essas lojas são comprovadas, escalonáveis e mais fáceis de gerenciar.
| Algas MarinhasFS | comparável ao Ceph | vantagem |
|---|---|---|
| Mestre | MDS | mais simples |
| Volume | OSD | otimizado para arquivos pequenos |
| Arquivador | Ceph FS | linearmente escalável, personalizável, O(1) ou O(logN) |
Voltar ao sumário
MinIO segue de perto o AWS S3 e é ideal para testes de API S3. Possui boa UI, políticas, versionamentos, etc. SeaweedFS está tentando se atualizar aqui. Também é possível colocar o MinIO como gateway na frente do SeaweedFS posteriormente.
Os metadados do MinIO estão em arquivos simples. Cada gravação de arquivo incorrerá em gravações extras no meta-arquivo correspondente.
MinIO não possui otimização para muitos arquivos pequenos. Os arquivos são simplesmente armazenados como estão em discos locais. Além do meta-arquivo extra e dos fragmentos para codificação de eliminação, isso apenas amplifica o problema do LOSF.
MinIO possui vários IO de disco para ler um arquivo. SeaweedFS possui leituras de disco O(1), mesmo para arquivos codificados para eliminação.
MinIO possui codificação de eliminação em tempo integral. SeaweedFS usa replicação em dados quentes para maior velocidade e, opcionalmente, aplica codificação de eliminação em dados quentes.
MinIO não tem suporte a API do tipo POSIX.
MinIO tem requisitos específicos de layout de armazenamento. Não é flexível ajustar a capacidade. No SeaweedFS, basta iniciar um servidor de volume apontando para o mestre. Isso é tudo.
Este é um projeto super emocionante! E precisamos de ajudantes e apoio!
Voltar ao sumário
Guia de instalação para usuários que não estão familiarizados com golang
Passo 1: instale, vá em sua máquina e configure o ambiente seguindo as instruções em:
https://golang.org/doc/install
certifique-se de definir seu $GOPATH
Etapa 2: verifique este repositório:
git clone https://github.com/seaweedfs/seaweedfs.gitEtapa 3: baixe, compile e instale o projeto executando o seguinte comando
cd seaweedfs/weed && make install Feito isso, você encontrará o executável "weed" em seu diretório $GOPATH/bin
Voltar ao sumário
Ao testar o desempenho de leitura no SeaweedFS, basicamente se torna um teste de desempenho da velocidade de leitura aleatória do seu disco rígido. Os discos rígidos geralmente obtêm 100 MB/s ~ 200 MB/s.
Para modificar ou excluir arquivos pequenos, o SSD deve excluir um bloco inteiro de cada vez e mover o conteúdo dos blocos existentes para um novo bloco. O SSD é rápido quando novo, mas ficará fragmentado com o tempo e você terá que coletar o lixo, compactando blocos. SeaweedFS é compatível com SSD, pois é apenas anexado. A exclusão e a compactação são feitas no nível do volume em segundo plano, não retardando a leitura e não causando fragmentação.
Voltar ao sumário
Meus próprios resultados não científicos de máquina única no Mac Book com disco de estado sólido, CPU: 1 Intel Core i7 2,6 GHz.
Escreva 1 milhão de arquivos de 1 KB:
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
Leia aleatoriamente 1 milhão de arquivos:
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.
Para ver estatísticas de solicitação segmentadas, use o parâmetro --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.
Voltar ao sumário
Licenciado sob a Licença Apache, Versão 2.0 (a "Licença"); você não pode usar este arquivo exceto em conformidade com a Licença. Você pode obter uma cópia da Licença em
http://www.apache.org/licenses/LICENSE-2.0
A menos que exigido pela lei aplicável ou acordado por escrito, o software distribuído sob a Licença é distribuído "COMO ESTÁ", SEM GARANTIAS OU CONDIÇÕES DE QUALQUER TIPO, expressas ou implícitas. Consulte a Licença para saber o idioma específico que rege as permissões e limitações da Licença.
O texto desta página está disponível para modificação e reutilização sob os termos da Licença Creative Commons Attribution-Sharealike 3.0 Unported e da GNU Free Documentation License (não versionada, sem seções invariáveis, textos de capa ou contracapa).
Voltar ao sumário
