seaweedfs
3.80
SeaweedFS es un proyecto independiente de código abierto con licencia Apache y su desarrollo continuo es posible en su totalidad gracias al apoyo de estos increíbles patrocinadores. Si desea fortalecer aún más SeaweedFS, considere unirse a nuestros patrocinadores en Patreon.
¡Tu apoyo será muy apreciado por mí y por otros seguidores!
docker run -p 8333:8333 chrislusf/seaweedfs server -s3
weed o weed.exe . O ejecute go install github.com/seaweedfs/seaweedfs/weed@latest .weed server -dir=/some/data/dir -s3 para iniciar un maestro, un servidor de volumen, un archivador y una puerta de enlace S3. Además, para aumentar la capacidad, simplemente agregue más servidores de volumen ejecutando weed volume -dir="/some/data/dir2" -mserver="<master_host>:9333" -port=8081 localmente, o en una máquina diferente, o en miles de máquinas. ¡Eso es todo!
SeaweedFS es un sistema de archivos distribuido simple y altamente escalable. Hay dos objetivos:
SeaweedFS comenzó como un almacén de objetos para manejar archivos pequeños de manera eficiente. En lugar de administrar todos los metadatos de archivos en un maestro central, el maestro central solo administra volúmenes en servidores de volúmenes, y estos servidores de volúmenes administran archivos y sus metadatos. Esto alivia la presión de concurrencia del maestro central y distribuye los metadatos de los archivos en los servidores de volumen, lo que permite un acceso más rápido a los archivos (O(1), generalmente una sola operación de lectura de disco).
Sólo hay 40 bytes de almacenamiento en disco para los metadatos de cada archivo. Es tan simple con las lecturas de disco O(1) que puede desafiar el rendimiento con sus casos de uso reales.
SeaweedFS comenzó implementando el documento de diseño Haystack de Facebook. Además, SeaweedFS implementa codificación de borrado con ideas de f4: el Warm BLOB Storage System de Facebook, y tiene muchas similitudes con el Tectonic Filesystem de Facebook.
Además del almacén de objetos, Filer opcional puede admitir directorios y atributos POSIX. Filer es un servidor independiente sin estado, escalable linealmente y con almacenes de metadatos personalizables, por ejemplo, MySql, Postgres, Redis, Cassandra, HBase, Mongodb, Elastic Search, LevelDB, RocksDB, Sqlite, MemSql, TiDB, Etcd, CockroachDB, YDB, etc.
Para cualquier almacén de valores clave distribuido, los valores grandes se pueden descargar a SeaweedFS. Con una velocidad de acceso rápida y una capacidad escalable linealmente, SeaweedFS puede funcionar como una tienda distribuida de gran valor clave.
SeaweedFS puede integrarse de forma transparente con la nube. Con datos activos en el clúster local y datos activos en la nube con un tiempo de acceso O(1), SeaweedFS puede lograr un tiempo de acceso local rápido y una capacidad elástica de almacenamiento en la nube. Además, se minimiza el coste de la API de acceso al almacenamiento en la nube. ¡Más rápido y económico que el almacenamiento directo en la nube!
Volver al índice
Volver al índice
Volver al índice
De forma predeterminada, el nodo maestro se ejecuta en el puerto 9333 y los nodos de volumen se ejecutan en el puerto 8080. Iniciemos un nodo maestro y dos nodos de volumen en los puertos 8080 y 8081. Idealmente, deberían iniciarse desde máquinas diferentes. Usaremos localhost como ejemplo.
SeaweedFS utiliza operaciones HTTP REST para leer, escribir y eliminar. Las respuestas están en formato JSON o 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 cargar un archivo: primero, envíe una solicitud HTTP POST, PUT o GET a /dir/assign para obtener un fid y una URL del servidor de volumen:
> curl http://localhost:9333/dir/assign
{"count":1,"fid":"3,01637037d6","url":"127.0.0.1:8080","publicUrl":"localhost:8080"}
En segundo lugar, para almacenar el contenido del archivo, envíe una solicitud POST HTTP de varias partes a url + '/' + fid de la respuesta:
> curl -F file=@/home/chris/myphoto.jpg http://127.0.0.1:8080/3,01637037d6
{"name":"myphoto.jpg","size":43234,"eTag":"1cc0118e"}
Para actualizar, envíe otra solicitud POST con el contenido del archivo actualizado.
Para eliminar, envíe una solicitud HTTP DELETE a la misma url + '/' + fid URL:
> curl -X DELETE http://127.0.0.1:8080/3,01637037d6
Ahora puede guardar el fid , 3,01637037d6 en este caso, en un campo de la base de datos.
El número 3 al principio representa una identificación de volumen. Después de la coma, hay una clave de archivo, 01, y una cookie de archivo, 637037d6.
La identificación del volumen es un entero de 32 bits sin signo. La clave del archivo es un entero de 64 bits sin signo. La cookie de archivo es un entero de 32 bits sin firmar que se utiliza para evitar adivinar la URL.
La clave del archivo y la cookie del archivo están codificadas en hexadecimal. Puede almacenar la tupla <identificador de volumen, clave de archivo, cookie de archivo> en su propio formato o simplemente almacenar el fid como una cadena.
Si se almacena como una cadena, en teoría, necesitaría 8+1+16+8=33 bytes. Un char(33) sería suficiente, si no más que suficiente, ya que la mayoría de los usos no necesitarán 2^32 volúmenes.
Si el espacio es realmente una preocupación, puede almacenar la identificación del archivo en su propio formato. Necesitaría un entero de 4 bytes para la identificación del volumen, un número de 8 bytes para la clave del archivo y un entero de 4 bytes para la cookie del archivo. Entonces 16 bytes son más que suficientes.
A continuación se muestra un ejemplo de cómo representar la URL.
Primero busque las URL del servidor de volúmenes por el ID de volumen del archivo:
> curl http://localhost:9333/dir/lookup?volumeId=3
{"volumeId":"3","locations":[{"publicUrl":"localhost:8080","url":"localhost:8080"}]}
Dado que (normalmente) no hay demasiados servidores de volúmenes y los volúmenes no se mueven con frecuencia, puede almacenar en caché los resultados la mayor parte del tiempo. Según el tipo de replicación, un volumen puede tener varias ubicaciones de réplica. Simplemente elija al azar una ubicación para leer.
Ahora puede tomar la URL pública, representar la URL o leerla directamente desde el servidor de volumen a través de la URL:
http://localhost:8080/3,01637037d6.jpg
Observe que aquí agregamos una extensión de archivo ".jpg". Es opcional y solo una forma para que el cliente especifique el tipo de contenido del archivo.
Si desea una URL más agradable, puede utilizar uno de estos 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
Si desea obtener una versión escalada de una imagen, puede agregar algunos 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 la estrategia de replicación a nivel de volumen. Entonces, cuando obtenga una identificación de archivo, puede especificar la estrategia de replicación. Por ejemplo:
curl http://localhost:9333/dir/assign?replication=001
Las opciones de los parámetros de replicación son:
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
Se pueden encontrar más detalles sobre la replicación en la wiki.
También puede configurar la estrategia de replicación predeterminada al iniciar el servidor maestro.
Los servidores de volumen se pueden iniciar con un nombre de centro de datos específico:
weed volume -dir=/tmp/1 -port=8080 -dataCenter=dc1
weed volume -dir=/tmp/2 -port=8081 -dataCenter=dc2
Al solicitar una clave de archivo, un parámetro "dataCenter" opcional puede limitar el volumen asignado al centro de datos específico. Por ejemplo, esto especifica que el volumen asignado debe limitarse a 'dc1':
http://localhost:9333/dir/assign?dataCenter=dc1
Volver al índice
Por lo general, los sistemas de archivos distribuidos dividen cada archivo en fragmentos, un maestro central mantiene una asignación de nombres de archivos, índices de fragmentos a identificadores de fragmentos y también qué fragmentos tiene cada servidor de fragmentos.
El principal inconveniente es que el maestro central no puede manejar muchos archivos pequeños de manera eficiente y, dado que todas las solicitudes de lectura deben pasar por el maestro de fragmentos, es posible que no se escale bien para muchos usuarios simultáneos.
En lugar de gestionar fragmentos, SeaweedFS gestiona volúmenes de datos en el servidor maestro. Cada volumen de datos tiene un tamaño de 32 GB y puede contener una gran cantidad de archivos. Y cada nodo de almacenamiento puede tener muchos volúmenes de datos. Por lo tanto, el nodo maestro solo necesita almacenar los metadatos sobre los volúmenes, que es una cantidad de datos bastante pequeña y generalmente estable.
Los metadatos del archivo real se almacenan en cada volumen en los servidores de volúmenes. Dado que cada servidor de volumen solo administra metadatos de archivos en su propio disco, con solo 16 bytes para cada archivo, todos los accesos a archivos pueden leer metadatos de archivos solo desde la memoria y solo necesitan una operación de disco para leer realmente los datos de archivos.
A modo de comparación, considere que una estructura de inodo xfs en Linux tiene 536 bytes.
La arquitectura es bastante simple. Los datos reales se almacenan en volúmenes en nodos de almacenamiento. Un servidor de volúmenes puede tener varios volúmenes y puede admitir acceso de lectura y escritura con autenticación básica.
Todos los volúmenes son administrados por un servidor maestro. El servidor maestro contiene la identificación del volumen y la asignación del servidor de volúmenes. Esta es información bastante estática y se puede almacenar en caché fácilmente.
En cada solicitud de escritura, el servidor maestro también genera una clave de archivo, que es un entero creciente sin signo de 64 bits. Dado que las solicitudes de escritura generalmente no son tan frecuentes como las solicitudes de lectura, un servidor maestro debería poder manejar bien la concurrencia.
Cuando un cliente envía una solicitud de escritura, el servidor maestro devuelve (ID de volumen, clave de archivo, cookie de archivo, URL del nodo de volumen) para el archivo. Luego, el cliente se comunica con el nodo de volumen y envía el contenido del archivo.
Cuando un cliente necesita leer un archivo en función de (identificación de volumen, clave de archivo, cookie de archivo), solicita al servidor maestro por la identificación de volumen (URL del nodo de volumen, URL pública del nodo de volumen), o lo recupera de un caché. Luego, el cliente puede OBTENER el contenido, o simplemente representar la URL en las páginas web y permitir que los navegadores obtengan el contenido.
Consulte el ejemplo para obtener detalles sobre el proceso de escritura y lectura.
En la implementación actual, cada volumen puede contener 32 gibibytes (32 GiB u 8x2^32 bytes). Esto se debe a que alineamos el contenido a 8 bytes. Podemos aumentar esto fácilmente a 64 GiB, o 128 GiB, o más, cambiando 2 líneas de código, a costa de desperdiciar espacio de relleno debido a la alineación.
Puede haber 4 gibibytes (4GiB o 2^32 bytes) de volúmenes. Entonces, el tamaño total del sistema es 8 x 4GiB x 4GiB, que son 128 exbibytes (128EiB o 2^67 bytes).
El tamaño de cada archivo individual está limitado al tamaño del volumen.
Toda la metainformación del archivo almacenada en un servidor de volumen se puede leer desde la memoria sin acceso al disco. Cada archivo requiere solo una entrada de mapa de 16 bytes de <clave de 64 bits, desplazamiento de 32 bits, tamaño de 32 bits>. Por supuesto, cada entrada del mapa tiene su propio coste de espacio para el mapa. Pero normalmente el espacio en disco se agota antes que la memoria.
Los servidores de volumen local son mucho más rápidos, mientras que los almacenamientos en la nube tienen una capacidad elástica y en realidad son más rentables si no se accede a ellos con frecuencia (normalmente la carga es gratuita, pero el acceso es relativamente costoso). Con la estructura de solo agregar y el tiempo de acceso O(1), SeaweedFS puede aprovechar el almacenamiento local y en la nube descargando los datos calientes a la nube.
Por lo general, los datos calientes son nuevos y los datos calientes son viejos. SeaweedFS coloca los volúmenes recién creados en servidores locales y, opcionalmente, carga los volúmenes más antiguos en la nube. Si se accede con menos frecuencia a los datos más antiguos, esto literalmente le brinda capacidad ilimitada con servidores locales limitados y aún así es rápido para los datos nuevos.
Con el tiempo de acceso O(1), el costo de latencia de la red se mantiene al mínimo.
Si los datos activos/calientes se dividen en 20/80, con 20 servidores, puede lograr una capacidad de almacenamiento de 100 servidores. ¡Eso es un ahorro de costos del 80%! O puede reutilizar los 80 servidores para almacenar también nuevos datos y obtener un rendimiento de almacenamiento 5 veces mayor.
Volver al índice
La mayoría de los demás sistemas de archivos distribuidos parecen más complicados de lo necesario.
SeaweedFS pretende ser rápido y sencillo, tanto en configuración como en funcionamiento. Si no entiendes cómo funciona cuando llegas aquí, ¡hemos fallado! Plantee un problema con cualquier pregunta o actualice este archivo con aclaraciones.
SeaweedFS avanza constantemente. Lo mismo con otros sistemas. Estas comparaciones pueden quedar obsoletas rápidamente. Por favor ayuda a mantenerlos actualizados.
Volver al índice
HDFS utiliza el enfoque de fragmentos para cada archivo y es ideal para almacenar archivos grandes.
SeaweedFS es ideal para entregar archivos relativamente más pequeños de forma rápida y simultánea.
SeaweedFS también puede almacenar archivos extra grandes dividiéndolos en fragmentos de datos manejables y almacenar los identificadores de archivo de los fragmentos de datos en un meta fragmento. Esto se gestiona mediante la herramienta "carga/descarga de malezas", y el maestro de malezas o los servidores de volumen son independientes al respecto.
Volver al índice
Las arquitecturas son prácticamente las mismas. SeaweedFS tiene como objetivo almacenar y leer archivos rápidamente, con una arquitectura simple y plana. Las principales diferencias son
| Sistema | Metadatos del archivo | Contenido del archivo leído | POSIX | API DESCANSO | Optimizado para una gran cantidad de archivos pequeños |
|---|---|---|---|---|---|
| AlgasFS | ID de volumen de búsqueda, almacenable en caché | O(1) búsqueda de disco | Sí | Sí | |
| Archivador SeaweedFS | Linealmente escalable, personalizable | O(1) búsqueda de disco | FUSIBLE | Sí | Sí |
| GlusterFS | hash | FUSIBLE, NFS | |||
| cef | hash + reglas | FUSIBLE | Sí | ||
| alcesfs | en la memoria | FUSIBLE | No | ||
| MiniIO | metaarchivo separado para cada archivo | Sí | No |
Volver al índice
GlusterFS almacena archivos, tanto directorios como contenido, en volúmenes configurables llamados "ladrillos".
GlusterFS divide la ruta y el nombre del archivo en identificadores, los asigna a volúmenes virtuales y luego los asigna a "ladrillos".
Volver al índice
MooseFS opta por descuidar el problema de los archivos pequeños. Según el manual de moosefs 3.0, "incluso un archivo pequeño ocupará 64 KB más 4 KB de sumas de comprobación y 1 KB para el encabezado", porque "fue diseñado inicialmente para guardar grandes cantidades (como varios miles) de archivos muy grandes".
MooseFS Master Server mantiene todos los metadatos en la memoria. El mismo problema que el nodo de nombre HDFS.
Volver al índice
Ceph se puede configurar de manera similar a SeaweedFS como un almacén de claves->blob. Es mucho más complicado, con la necesidad de soportar capas encima. Aquí hay una comparación más detallada.
SeaweedFS tiene un grupo maestro centralizado para buscar volúmenes libres, mientras que Ceph utiliza servidores de hash y metadatos para localizar sus objetos. Tener un maestro centralizado facilita la codificación y la administración.
Ceph, al igual que SeaweedFS, se basa en el almacén de objetos RADOS. Ceph es bastante complicado y tiene críticas mixtas.
Ceph utiliza hash CRUSH para administrar automáticamente la ubicación de los datos, lo cual es eficiente para localizar los datos. Pero los datos deben colocarse según el algoritmo CRUSH. Cualquier configuración incorrecta provocaría la pérdida de datos. Los cambios de topología, como agregar nuevos servidores para aumentar la capacidad, provocarán una migración de datos con un alto costo de IO para adaptarse al algoritmo CRUSH. SeaweedFS coloca datos asignándolos a cualquier volumen grabable. Si falla la escritura en un volumen, simplemente elija otro volumen para escribir. Agregar más volúmenes también es lo más sencillo posible.
SeaweedFS está optimizado para archivos pequeños. Los archivos pequeños se almacenan como un bloque continuo de contenido, con un máximo de 8 bytes no utilizados entre archivos. El acceso a archivos pequeños es lectura de disco O(1).
SeaweedFS Filer utiliza tiendas disponibles en el mercado, como MySql, Postgres, Sqlite, Mongodb, Redis, Elastic Search, Cassandra, HBase, MemSql, TiDB, CockroachCB, Etcd, YDB, para administrar directorios de archivos. Estas tiendas están probadas, son escalables y más fáciles de administrar.
| AlgasFS | comparable a Ceph | ventaja |
|---|---|---|
| Maestro | MDS | más simple |
| Volumen | OSD | optimizado para archivos pequeños |
| declarante | Ceph FS | linealmente escalable, personalizable, O(1) u O(logN) |
Volver al índice
MinIO sigue de cerca AWS S3 y es ideal para probar la API de S3. Tiene buena interfaz de usuario, políticas, versiones, etc. SeaweedFS está tratando de ponerse al día aquí. También es posible colocar MinIO como puerta de enlace frente a SeaweedFS más adelante.
Los metadatos de MinIO están en archivos simples. Cada escritura de archivo generará escrituras adicionales en el metaarchivo correspondiente.
MinIO no tiene optimización para muchos archivos pequeños. Los archivos simplemente se almacenan tal cual en discos locales. Además del metaarchivo adicional y los fragmentos para la codificación de borrado, solo amplifica el problema LOSF.
MinIO tiene múltiples discos IO para leer un archivo. SeaweedFS tiene lecturas de disco O(1), incluso para archivos codificados de borrado.
MinIO tiene codificación de borrado a tiempo completo. SeaweedFS utiliza replicación de datos calientes para una velocidad más rápida y, opcionalmente, aplica codificación de borrado en datos calientes.
MinIO no tiene soporte API similar a POSIX.
MinIO tiene requisitos específicos sobre el diseño del almacenamiento. No es flexible ajustar la capacidad. En SeaweedFS, simplemente inicie un servidor de volumen apuntando al maestro. Eso es todo.
¡Este es un proyecto súper emocionante! ¡Y necesitamos ayuda y apoyo!
Volver al índice
Guía de instalación para usuarios que no están familiarizados con golang
Paso 1: instale, vaya a su máquina y configure el entorno siguiendo las instrucciones en:
https://golang.org/doc/install
asegúrese de definir su $GOPATH
Paso 2: consulte este repositorio:
git clone https://github.com/seaweedfs/seaweedfs.gitPaso 3: descargue, compile e instale el proyecto ejecutando el siguiente comando
cd seaweedfs/weed && make install Una vez hecho esto, encontrará el ejecutable "weed" en su directorio $GOPATH/bin
Volver al índice
Cuando se prueba el rendimiento de lectura en SeaweedFS, básicamente se convierte en una prueba de rendimiento de la velocidad de lectura aleatoria de su disco duro. Los discos duros suelen alcanzar entre 100 MB/s y 200 MB/s.
Para modificar o eliminar archivos pequeños, SSD debe eliminar un bloque completo a la vez y mover el contenido de los bloques existentes a un bloque nuevo. El SSD es rápido cuando es nuevo, pero se fragmentará con el tiempo y tendrás que recolectar basura y compactar los bloques. SeaweedFS es compatible con SSD ya que solo se puede agregar. La eliminación y compactación se realizan a nivel de volumen en segundo plano, sin ralentizar la lectura ni provocar fragmentación.
Volver al índice
Mis propios resultados no científicos de una sola máquina en Mac Book con disco de estado sólido, CPU: 1 Intel Core i7 a 2,6 GHz.
Escriba 1 millón de archivos 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
Lea aleatoriamente 1 millón de archivos:
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 estadísticas de solicitudes segmentadas, utilice el 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.
Volver al índice
Licenciado bajo la Licencia Apache, Versión 2.0 (la "Licencia"); no puede utilizar este archivo excepto de conformidad con la Licencia. Puede obtener una copia de la Licencia en
http://www.apache.org/licenses/LICENSE-2.0
A menos que lo exija la ley aplicable o se acuerde por escrito, el software distribuido bajo la Licencia se distribuye "TAL CUAL", SIN GARANTÍAS NI CONDICIONES DE NINGÚN TIPO, ya sean expresas o implícitas. Consulte la Licencia para conocer el idioma específico que rige los permisos y limitaciones de la Licencia.
El texto de esta página está disponible para modificación y reutilización bajo los términos de la licencia Creative Commons Attribution-Sharealike 3.0 Unported y la licencia de documentación libre GNU (sin versiones, sin secciones invariantes, textos de portada o textos de contraportada).
Volver al índice
