SeaweedFS

<h2 align="center"><a href="https://www.patreon.com/seaweedfs">通过 Patreon 赞助 SeaweedFS</a></h2>

SeaweedFS 是一个独立的 Apache 许可的开源项目，其持续开发完全依赖于这些令人敬佩的支持者的支持。如果您想让 SeaweedFS 变得更加强大，请考虑加入我们的<a href="https://www.patreon.com/seaweedfs">Patreon 赞助者</a>。

您的支持将得到我和其他支持者的真诚感谢！

黄金赞助商

---

• 下载不同平台的二进制文件
• SeaweedFS Slack 频道
• SeaweedFS Twitter
• SeaweedFS Telegram
• SeaweedFS Reddit
• SeaweedFS 邮件列表
• Wiki 文档
• SeaweedFS 白皮书
• SeaweedFS 介绍幻灯片 2021.5
• SeaweedFS 介绍幻灯片 2019.3

目录

• 快速入门
  • Docker 上的 S3 API 快速入门
  • 单一二进制文件快速入门
  • AWS 上的 SeaweedFS S3 快速入门
• 简介
• 特性
  • 附加特性
  • Filer 特性
• 示例：使用 Seaweed 对象存储
• 架构
• 与其他文件系统的比较
  • 与 HDFS 的比较
  • 与 GlusterFS、Ceph 的比较
  • 与 GlusterFS 的比较
  • 与 Ceph 的比较
  • 与 Minio 的比较
• 开发计划
• 安装指南
• 磁盘相关主题
• 基准测试
• 许可证

快速入门

Docker 上的 S3 API 快速入门

docker run -p 8333:8333 chrislusf/seaweedfs server -s3

单一二进制文件快速入门

• 从 https://github.com/seaweedfs/seaweedfs/releases 下载最新的二进制文件并解压得到单个二进制文件 weed 或 weed.exe。或者运行 go install github.com/seaweedfs/seaweedfs/weed@latest。
• 运行 weed server -dir=/some/data/dir -s3 启动一个主服务器、一个卷服务器、一个 filer 和一个 S3 网关。

此外，要增加容量，只需通过在本地或不同的机器上运行 weed volume -dir="/some/data/dir2" -mserver="<master_host>:9333" -port=8081 来添加更多卷服务器即可。就是这么简单！

AWS 上的 SeaweedFS S3 快速入门

• 使用 cloudformation 设置快速生产就绪的 AWS 上的 SeaweedFS S3

简介

SeaweedFS 是一个简单且高度可扩展的分布式文件系统。它有两个目标：

1. 存储数十亿个文件！
2. 快速提供文件服务！

SeaweedFS 最初是作为一个对象存储来高效处理小文件。 与在中央主服务器中管理所有文件元数据不同， 中央主服务器只管理卷服务器上的卷， 而这些卷服务器管理文件及其元数据。 这减轻了中央主服务器的并发压力，并将文件元数据分散到卷服务器中， 实现更快的文件访问（O(1)，通常只需一次磁盘读取操作）。

每个文件的元数据只需要 40 字节的磁盘存储开销。 它非常简单，只需 O(1) 次磁盘读取，欢迎您用实际用例来挑战其性能。

SeaweedFS 最初是通过实现 Facebook 的 Haystack 设计论文 开始的。 此外，SeaweedFS 还借鉴了 f4：Facebook 的温 BLOB 存储系统 中的想法实现了纠删码，并与 Facebook 的 Tectonic 文件系统 有很多相似之处。

在对象存储之上，可选的 Filer 可以支持目录和 POSIX 属性。 Filer 是一个独立的线性可扩展无状态服务器，具有可定制的元数据存储， 例如 MySql、Postgres、Redis、Cassandra、HBase、Mongodb、Elastic Search、LevelDB、RocksDB、Sqlite、MemSql、TiDB、Etcd、CockroachDB、YDB 等。

对于任何分布式键值存储，大型值可以被卸载到 SeaweedFS。 凭借快速的访问速度和线性可扩展的容量， SeaweedFS 可以作为分布式键-大值存储使用。 SeaweedFS 可以无缝集成云存储。本地集群存储热数据,云端存储温数据,访问时间复杂度为 O(1),SeaweedFS 既能实现快速本地访问,又能获得弹性云存储容量。更重要的是,云存储 API 调用成本降到最低。比直接使用云存储更快更便宜!

返回目录

功能

附加功能

• 可选择无复制或不同级别的复制,支持机架和数据中心感知。
• 主服务器自动故障转移 - 无单点故障(SPOF)。
• 根据文件 MIME 类型自动 Gzip 压缩。
• 删除或更新后自动压缩以回收磁盘空间。
• 自动条目 TTL 过期。
• 任何有磁盘空间的服务器都可以增加总存储空间。
• 添加/删除服务器不会导致数据重新平衡,除非由管理员命令触发。
• 可选的图片大小调整。
• 支持 ETag、Accept-Range、Last-Modified 等。
• 支持内存/leveldb/只读模式调优,以平衡内存和性能。
• 支持可写和只读卷的重新平衡。
• 可定制的多级存储:可定制存储磁盘类型以平衡性能和成本。
• 透明云集成:通过分层云存储实现温数据的无限容量。
• 用于温存储的纠删码 机架感知 10.4 纠删码降低存储成本并提高可用性。

返回目录

Filer 功能

• Filer 服务器通过 HTTP 提供"普通"的目录和文件。
• 文件 TTL自动使文件元数据和实际文件数据过期。
• 挂载 filer通过 FUSE 直接读写文件作为本地目录。
• Filer 存储复制为 filer 元数据存储启用高可用。
• 主动-主动复制支持跨集群的异步单向或双向连续复制。
• Amazon S3 兼容 API使用 S3 工具访问文件。
• Hadoop 兼容文件系统从 Hadoop/Spark/Flink 等访问文件,甚至可以运行 HBase。
• 异步复制到云具有极快的本地访问速度,并可备份到 Amazon S3、Google Cloud Storage、Azure、BackBlaze。
• WebDAV 作为 Mac 和 Windows 的映射驱动器访问,或从移动设备访问。
• AES256-GCM 加密存储安全地存储加密数据。
• 超大文件存储大型或超大型文件,可达数十 TB。
• 云驱动将云存储挂载到本地集群,缓存以实现快速读写,异步回写。
• 远程对象存储网关除了云驱动外,还将桶操作镜像到远程对象存储。

Kubernetes

• Kubernetes CSI 驱动 容器存储接口(CSI)驱动程序。
• SeaweedFS 操作符

返回目录

示例:使用 Seaweed 对象存储

默认情况下,主节点运行在 9333 端口,卷节点运行在 8080 端口。 让我们启动一个主节点,以及两个分别运行在 8080 和 8081 端口的卷节点。理想情况下,它们应该在不同的机器上启动。我们将使用 localhost 作为示例。

SeaweedFS 使用 HTTP REST 操作进行读取、写入和删除。响应以 JSON 或 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 &

写入文件

要上传文件:首先,向 /dir/assign 发送 HTTP POST、PUT 或 GET 请求以获取 fid 和卷服务器 URL:

> curl http://localhost:9333/dir/assign
{"count":1,"fid":"3,01637037d6","url":"127.0.0.1:8080","publicUrl":"localhost:8080"}

其次,要存储文件内容,向响应中的 url + '/' + fid 发送 HTTP 多部分 POST 请求:

> curl -F file=@/home/chris/myphoto.jpg http://127.0.0.1:8080/3,01637037d6
{"name":"myphoto.jpg","size":43234,"eTag":"1cc0118e"}

要更新,请发送另一个带有更新文件内容的 POST 请求。

要删除,向相同的 url + '/' + fid URL 发送 HTTP DELETE 请求:

> curl -X DELETE http://127.0.0.1:8080/3,01637037d6

保存文件 ID

现在,您可以将 fid (在本例中为 3,01637037d6)保存到数据库字段中。

开头的数字 3 表示卷 ID。逗号后是一个文件键 01 和一个文件 cookie 637037d6。

卷 ID 是一个无符号 32 位整数。文件键是一个无符号 64 位整数。文件 cookie 是一个无符号 32 位整数,用于防止 URL 猜测。

文件键和文件 cookie 都以十六进制编码。您可以以自己的格式存储 <卷 ID,文件键,文件 cookie> 元组,或者简单地将 fid 存储为字符串。

如果存储为字符串,理论上您需要 8+1+16+8=33 个字节。char(33) 应该足够,如果不是绰绰有余的话,因为大多数用途不需要 2^32 个卷。

如果空间确实是一个问题,您可以以自己的格式存储文件 ID。您需要一个 4 字节整数用于卷 ID,8 字节长数字用于文件键,以及一个 4 字节整数用于文件 cookie。因此,16 字节绰绰有余。

读取文件

以下是如何渲染 URL 的示例。

首先通过文件的 volumeId 查找卷服务器的 URL:

> curl http://localhost:9333/dir/lookup?volumeId=3
{"volumeId":"3","locations":[{"publicUrl":"localhost:8080","url":"localhost:8080"}]}

由于(通常)卷服务器不会太多,而且卷不经常移动,因此大多数时候您可以缓存结果。根据复制类型,一个卷可能有多个副本位置。只需随机选择一个位置进行读取。

现在您可以使用公共 URL,渲染 URL 或直接通过 URL 从卷服务器读取:

 http://localhost:8080/3,01637037d6.jpg

请注意,我们在这里添加了文件扩展名".jpg"。这是可选的,只是客户端指定文件内容类型的一种方式。

如果您想要一个更好看的 URL,可以使用以下替代 URL 格式之一:

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

如果你想获取图片的缩放版本，可以添加一些参数:

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在卷级别应用复制策略。因此，当你获取文件ID时，可以指定复制策略。例如:

curl http://localhost:9333/dir/assign?replication=001

复制参数选项如下:

000: 不复制
001: 在同一机架上复制一次
010: 在不同机架但相同数据中心复制一次
100: 在不同数据中心复制一次
200: 在两个不同的数据中心复制两次
110: 在不同机架复制一次，在不同数据中心复制一次

关于复制的更多细节可以在wiki上找到。

你也可以在启动主服务器时设置默认的复制策略。

在特定数据中心分配文件键

卷服务器可以使用特定的数据中心名称启动:

 weed volume -dir=/tmp/1 -port=8080 -dataCenter=dc1
 weed volume -dir=/tmp/2 -port=8081 -dataCenter=dc2

在请求文件键时，可选的"dataCenter"参数可以将分配的卷限制在特定的数据中心。例如，这指定分配的卷应限制在'dc1':

 http://localhost:9333/dir/assign?dataCenter=dc1

其他特性

• 无单点故障
• 使用你自己的键插入
• 大文件分块
• 集合作为简单命名空间

返回目录

对象存储架构

通常分布式文件系统将每个文件分割成块，中央主服务器保存文件名、块索引到块句柄的映射，以及每个块服务器拥有哪些块。

主要缺点是中央主服务器无法有效处理许多小文件，而且由于所有读取请求都需要通过块主服务器，因此可能无法很好地扩展以支持多个并发用户。

SeaweedFS不管理块，而是在主服务器中管理数据卷。每个数据卷大小为32GB，可以容纳大量文件。每个存储节点可以有多个数据卷。因此主节点只需要存储关于卷的元数据，这是相当少量的数据，而且通常是稳定的。

实际的文件元数据存储在卷服务器上的每个卷中。由于每个卷服务器只管理自己磁盘上文件的元数据，每个文件只需16字节，所有文件访问都可以直接从内存读取文件元数据，只需要一次磁盘操作来实际读取文件数据。

相比之下，考虑到Linux中的xfs inode结构是536字节。

主服务器和卷服务器

架构相当简单。实际数据存储在存储节点的卷中。一个卷服务器可以有多个卷，并且可以支持基本身份验证的读写访问。

所有卷由主服务器管理。主服务器包含卷id到卷服务器的映射。这是相当静态的信息，可以很容易地被缓存。

在每个写请求上，主服务器还会生成一个文件键，这是一个不断增长的64位无符号整数。由于写请求通常不如读请求频繁，一个主服务器应该能够很好地处理并发。

写入和读取文件

当客户端发送写请求时，主服务器返回文件的(卷id、文件键、文件cookie、卷节点URL)。然后客户端联系卷节点并POST文件内容。

当客户端需要基于(卷id、文件键、文件cookie)读取文件时，它通过卷id向主服务器询问(卷节点URL、卷节点公共URL)，或者从缓存中检索这些信息。然后客户端可以GET内容，或者只在网页上渲染URL并让浏览器获取内容。

请参阅示例以了解写入-读取过程的详细信息。

存储大小

在当前实现中，每个卷可以容纳32 gibibytes (32GiB或8x2^32字节)。这是因为我们将内容对齐到8字节。我们可以很容易地将其增加到64GiB、128GiB或更多，只需更改2行代码，代价是由于对齐而浪费一些填充空间。

可以有4 gibibytes (4GiB或2^32字节)的卷。因此总系统大小为8 x 4GiB x 4GiB，即128 exbibytes (128EiB或2^67字节)。

每个单独文件的大小限制为卷大小。

节省内存

存储在卷服务器上的所有文件元信息可以从内存中读取，无需磁盘访问。每个文件只占用16字节的映射条目<64位键, 32位偏移量, 32位大小>。当然，每个映射条目都有自己的映射空间成本。但通常磁盘空间比内存先用完。

分层存储到云

本地卷服务器速度更快，而云存储具有弹性容量，如果不经常访问实际上更具成本效益(通常上传免费，但访问相对昂贵)。凭借追加只写结构和O(1)访问时间，SeaweedFS可以通过将温数据卸载到云来利用本地和云存储的优势。

通常热数据是新的，温数据是旧的。SeaweedFS将新创建的卷放在本地服务器上，并可选择将较旧的卷上传到云。如果较旧的数据访问频率较低，这实际上为你提供了无限容量的有限本地服务器，而且对新数据仍然很快。

凭借O(1)访问时间，网络延迟成本保持在最低水平。

如果热/温数据按20/80分割，使用20台服务器，你可以实现100台服务器的存储容量。这节省了80%的成本！或者你也可以重新利用这80台服务器来存储新数据，获得5倍的存储吞吐量。

返回目录

与其他文件系统比较

大多数其他分布式文件系统似乎比必要的更复杂。

SeaweedFS旨在快速简单，无论是在设置还是操作方面。如果你读到这里还不理解它是如何工作的，那我们就失败了！请提出任何问题或更新此文件以澄清。

SeaweedFS在不断前进。其他系统也是如此。这些比较可能很快就过时了。请帮助保持它们更新。

返回目录

与HDFS相比

HDFS对每个文件使用块方法，非常适合存储大文件。

SeaweedFS非常适合快速并发地提供相对较小的文件。

SeaweedFS还可以通过将超大文件分割成可管理的数据块来存储，并将数据块的文件ID存储到元数据块中。这由"weed upload/download"工具管理，weed主服务器或卷服务器对此不知情。

返回目录

与GlusterFS、Ceph相比

架构大多相同。SeaweedFS旨在快速存储和读取文件，具有简单和扁平的架构。主要区别是:

• SeaweedFS针对小文件进行优化，确保O(1)磁盘查找操作，也可以处理大文件。
• SeaweedFS静态分配文件的卷ID。定位文件内容只需查找卷ID，这可以很容易地被缓存。
• SeaweedFS Filer元数据存储可以是任何知名且经过验证的数据存储，例如Redis、Cassandra、HBase、Mongodb、Elastic Search、MySql、Postgres、Sqlite、MemSql、TiDB、CockroachDB、Etcd、YDB等，并且易于定制。
• SeaweedFS卷服务器还通过HTTP直接与客户端通信，支持范围查询、直接上传等。 | 系统 | 文件元数据 | 文件内容读取| POSIX | REST API | 针对大量小文件优化 | | ------------- | ------------------------------- | ---------------- | ------ | -------- | ------------------------- | | SeaweedFS | 查找卷ID，可缓存 | O(1)磁盘寻道 | | 是 | 是 | | SeaweedFS Filer| 线性可扩展，可定制 | O(1)磁盘寻道 | FUSE | 是 | 是 | | GlusterFS | 哈希 | | FUSE, NFS | | | | Ceph | 哈希 + 规则 | | FUSE | 是 | | | MooseFS | 内存中 | | FUSE | | 否 | | MinIO | 每个文件单独的元数据文件 | | | 是 | 否 |

返回目录

与GlusterFS比较

GlusterFS将文件（包括目录和内容）存储在可配置的称为"砖块"的卷中。

GlusterFS将路径和文件名哈希成ID，分配给虚拟卷，然后映射到"砖块"。

返回目录

与MooseFS比较

MooseFS选择忽视小文件问题。根据MooseFS 3.0手册，"即使是小文件也会占用64KiB，另外还有4KiB用于校验和，1KiB用于头部"，因为它"最初设计用于存储大量（如数千个）非常大的文件"。

MooseFS主服务器将所有元数据保存在内存中。这与HDFS namenode存在相同的问题。

返回目录

与Ceph比较

Ceph可以设置成类似SeaweedFS的键值存储。它更加复杂，需要支持上层结构。这里有一个更详细的比较

SeaweedFS有一个集中式的主服务器组来查找空闲卷，而Ceph使用哈希和元数据服务器来定位对象。有一个集中式主服务器使得编码和管理变得容易。

Ceph和SeaweedFS一样，都基于对象存储RADOS。Ceph相当复杂，评价不一。

Ceph使用CRUSH哈希自动管理数据放置，这对定位数据很有效。但数据必须按照CRUSH算法放置。任何错误配置都会导致数据丢失。拓扑变化，如增加新服务器以增加容量，将导致数据迁移，产生高IO成本以适应CRUSH算法。SeaweedFS通过将数据分配给任何可写卷来放置数据。如果写入一个卷失败，只需选择另一个卷写入。增加更多卷也同样简单。

SeaweedFS针对小文件进行了优化。小文件作为一个连续的内容块存储，文件之间最多有8个未使用字节。小文件访问是O(1)磁盘读取。

SeaweedFS Filer使用现成的存储系统，如MySQL、Postgres、Sqlite、MongoDB、Redis、Elastic Search、Cassandra、HBase、MemSQL、TiDB、CockroachDB、Etcd、YDB来管理文件目录。这些存储系统已经过验证，可扩展，更易于管理。

SeaweedFS	相当于Ceph中的	优势
Master	MDS	更简单
Volume	OSD	针对小文件优化
Filer	Ceph FS	线性可扩展，可定制，O(1)或O(logN)

返回目录

与MinIO比较

MinIO紧密遵循AWS S3，非常适合S3 API测试。它有良好的UI、策略、版本控制等。SeaweedFS正在努力赶上这一点。未来也可能将MinIO作为SeaweedFS前端的网关。

MinIO的元数据存储在简单的文件中。每次文件写入都会引发对应元数据文件的额外写入。

MinIO没有针对大量小文件进行优化。文件按原样存储在本地磁盘上。 再加上额外的元数据文件和纠删码分片，这只会放大LOSF（大量小文件）问题。

MinIO读取一个文件需要多次磁盘IO。SeaweedFS即使对于纠删码文件也只需O(1)次磁盘读取。

MinIO全时间使用纠删码。SeaweedFS对热数据使用复制以获得更快的速度，并可选择对温数据应用纠删码。

MinIO不支持类POSIX的API。

MinIO对存储布局有特定要求。调整容量不够灵活。在SeaweedFS中，只需启动一个指向主服务器的卷服务器即可。就这么简单。

开发计划

• 更多工具和文档，关于如何管理和扩展系统。
• 读写流数据。
• 支持结构化数据。

这是一个非常令人兴奋的项目！我们需要帮助者和支持！

返回目录

安装指南

针对不熟悉 golang 的用户的安装指南

步骤1：在你的机器上安装 go 并按照以下说明设置环境：

https://golang.org/doc/install

确保定义你的 $GOPATH

步骤2：检出此仓库：

git clone https://github.com/seaweedfs/seaweedfs.git

步骤3：通过执行以下命令下载、编译并安装项目

cd seaweedfs/weed && make install

完成后，你会在 $GOPATH/bin 目录下找到可执行文件 "weed"

返回目录

磁盘相关主题

硬盘性能

在SeaweedFS上测试读取性能时，基本上就变成了对硬盘随机读取速度的性能测试。硬盘通常能达到100MB/s~200MB/s。

固态硬盘

要修改或删除小文件，SSD必须一次删除整个块，并将现有块中的内容移动到新块。SSD在全新时很快，但随着时间推移会变得碎片化，你必须进行垃圾回收，压缩块。SeaweedFS对SSD友好，因为它是仅追加的。删除和压缩在后台以卷为单位进行，不会减慢读取速度，也不会造成碎片化。

返回目录

基准测试

我自己在配备固态硬盘的 MacBook 上进行的非科学单机测试结果，CPU：1个Intel Core i7 2.6GHz。

写入100万个1KB文件：

并发级别：      16
测试耗时：   66.753 秒
完成请求数：      1048576
失败请求数：        0
总传输量：      1106789009 字节
每秒请求数：    15708.23 [#/秒]
传输速率：          16191.69 [KB/秒]

连接时间 (毫秒)
              最小      平均        最大      标准差
总计：        0.3      1.0       84.3      0.9

一定时间内完成的请求百分比 (毫秒)
   50%      0.8 毫秒
   66%      1.0 毫秒
   75%      1.1 毫秒
   80%      1.2 毫秒
   90%      1.4 毫秒
   95%      1.7 毫秒
   98%      2.1 毫秒
   99%      2.6 毫秒
  100%     84.3 毫秒

随机读取100万个文件：

并发级别：      16
测试耗时：   22.301 秒
完成请求数：      1048576
失败请求数：        0
总传输量：      1106812873 字节
每秒请求数：    47019.38 [#/秒]
传输速率：          48467.57 [KB/秒]

连接时间 (毫秒)
              最小      平均        最大      标准差
总计：        0.0      0.3       54.1      0.2

一定时间内完成的请求百分比 (毫秒)
   50%      0.3 毫秒
   90%      0.4 毫秒
   98%      0.6 毫秒
   99%      0.7 毫秒
  100%     54.1 毫秒

运行WARP并启动混合基准测试。

make benchmark
warp: 基准测试数据已写入 "warp-mixed-2023-10-16[102354]-l70a.csv.zst"                                                                                                                                                                                               
混合操作。
操作：DELETE，10%，并发：20，运行时间4分59秒。
 * 吞吐量：6.19 对象/秒

操作：GET，45%，并发：20，运行时间5分钟。
 * 吞吐量：279.85 MiB/秒，27.99 对象/秒

操作：PUT，15%，并发：20，运行时间5分钟。
 * 吞吐量：89.86 MiB/秒，8.99 对象/秒

操作：STAT，30%，并发：20，运行时间5分钟。
 * 吞吐量：18.63 对象/秒

集群总计：369.74 MiB/秒，61.79 对象/秒，5分钟内0个错误。

要查看分段请求统计信息，请使用 --analyze.v 参数。

warp analyze --analyze.v warp-mixed-2023-10-16[102354]-l70a.csv.zst
已加载18642个操作... 完成！
混合操作。
----------------------------------------
操作：DELETE - 总计：1854，10.0%，并发：20，运行时间5分钟，开始时间2023-10-16 10:23:57.115 +0500 +05
 * 吞吐量：6.19 对象/秒
考虑的请求数: 1855:
* 平均: 104毫秒, 50%: 30毫秒, 90%: 207毫秒, 99%: 1.355秒, 最快: 1毫秒, 最慢: 4.613秒, 标准差: 320毫秒

----------------------------------------
操作: GET - 总计: 8388, 45.3%, 大小: 10485760 字节. 并发: 20, 运行时间 5分0秒, 开始时间 2023-10-16 10:23:57.12 +0500 +05
* 吞吐量: 279.77 MiB/秒, 27.98 对象/秒

考虑的请求数: 8389:
* 平均: 221毫秒, 50%: 106毫秒, 90%: 492毫秒, 99%: 1.739秒, 最快: 8毫秒, 最慢: 8.633秒, 标准差: 383毫秒
* TTFB: 平均: 81毫秒, 最佳: 2毫秒, 25%: 24毫秒, 中位数: 39毫秒, 75%: 65毫秒, 90%: 171毫秒, 99%: 669毫秒, 最差: 4.783秒 标准差: 163毫秒
* 首次访问: 平均: 240毫秒, 50%: 105毫秒, 90%: 511毫秒, 99%: 2.08秒, 最快: 12毫秒, 最慢: 8.633秒, 标准差: 480毫秒
* 首次访问TTFB: 平均: 88毫秒, 最佳: 2毫秒, 25%: 24毫秒, 中位数: 38毫秒, 75%: 64毫秒, 90%: 179毫秒, 99%: 919毫秒, 最差: 4.783秒 标准差: 199毫秒
* 最后访问: 平均: 219毫秒, 50%: 106毫秒, 90%: 463毫秒, 99%: 1.782秒, 最快: 9毫秒, 最慢: 8.633秒, 标准差: 416毫秒
* 最后访问TTFB: 平均: 81毫秒, 最佳: 2毫秒, 25%: 24毫秒, 中位数: 39毫秒, 75%: 65毫秒, 90%: 161毫秒, 99%: 657毫秒, 最差: 4.783秒 标准差: 176毫秒

----------------------------------------
操作: PUT - 总计: 2688, 14.5%, 大小: 10485760 字节. 并发: 20, 运行时间 5分0秒, 开始时间 2023-10-16 10:23:57.115 +0500 +05
* 吞吐量: 89.83 MiB/秒, 8.98 对象/秒

考虑的请求数: 2689:
* 平均: 1.165秒, 50%: 878毫秒, 90%: 2.015秒, 99%: 5.74秒, 最快: 99毫秒, 最慢: 8.264秒, 标准差: 968毫秒

----------------------------------------
操作: STAT - 总计: 5586, 30.2%, 并发: 20, 运行时间 5分0秒, 开始时间 2023-10-16 10:23:57.113 +0500 +05
* 吞吐量: 18.63 对象/秒

考虑的请求数: 5587:
* 平均: 15毫秒, 50%: 11毫秒, 90%: 34毫秒, 99%: 80毫秒, 最快: 0秒, 最慢: 245毫秒, 标准差: 17毫秒
* 首次访问: 平均: 14毫秒, 50%: 10毫秒, 90%: 33毫秒, 99%: 69毫秒, 最快: 0秒, 最慢: 203毫秒, 标准差: 16毫秒
* 最后访问: 平均: 15毫秒, 50%: 11毫秒, 90%: 34毫秒, 99%: 74毫秒, 最快: 0秒, 最慢: 203毫秒, 标准差: 17毫秒

集群总计: 369.64 MiB/秒, 61.77 对象/秒, 5分0秒内0个错误。
总错误数:0。

根据Apache许可证2.0版授权；
除非符合许可证的要求，否则您不得使用此文件。
您可以在以下位置获取许可证的副本：

    http://www.apache.org/licenses/LICENSE-2.0

除非适用法律要求或书面同意，根据许可证分发的软件是基于"按原样"的基础分发的，
不附带任何明示或暗示的担保或条件。
有关许可证下的特定语言管理权限和限制，请参阅许可证。

本页面的文本可根据知识共享署名-相同方式共享3.0未本地化许可证和GNU自由文档许可证（无版本，无不变部分，无封面文字或封底文字）的条款进行修改和重用。

随时间推移的星标用户