seaweedfs
3.80
SeaweedFS は、Apache ライセンスを取得した独立したオープン ソース プロジェクトであり、継続的な開発はもっぱらこれらの素晴らしい支援者のサポートのおかげで可能になりました。 SeaweedFS をさらに強力に成長させたい場合は、Patreon でスポンサーに参加することを検討してください。
あなたのサポートは私と他のサポーターにとって本当に感謝しています！
docker run -p 8333:8333 chrislusf/seaweedfs server -s3
weedまたはweed.exeを解凍します。または、 go install github.com/seaweedfs/seaweedfs/weed@latest実行します。weed server -dir=/some/data/dir -s3実行して、1 つのマスター、1 つのボリューム サーバー、1 つのファイラー、および 1 つの S3 ゲートウェイを起動します。また、容量を増やすには、 weed volume -dir="/some/data/dir2" -mserver="<master_host>:9333" -port=8081ローカルで実行するか、別のマシンで実行するか、または何千ものマシン。それです！
SeaweedFS は、シンプルで拡張性の高い分散ファイル システムです。目的は 2 つあります。
SeaweedFS は、小さなファイルを効率的に処理するためのオブジェクト ストアとして始まりました。中央マスターですべてのファイルのメタデータを管理するのではなく、中央マスターはボリューム サーバー上のボリュームのみを管理し、これらのボリューム サーバーはファイルとそのメタデータを管理します。これにより、中央マスターからの同時実行の圧力が軽減され、ファイルのメタデータがボリューム サーバーに分散され、より高速なファイル アクセス (O(1)、通常は 1 回のディスク読み取り操作のみ) が可能になります。
各ファイルのメタデータのディスク ストレージ オーバーヘッドはわずか 40 バイトです。 O(1) ディスク読み取りで非常に簡単なので、実際の使用例でパフォーマンスに挑戦してみてください。
SeaweedFS は Facebook の Haystack 設計書を実装することから始まりました。また、SeaweedFS は、f4 (Facebook の Warm BLOB ストレージ システム) のアイデアを使用して消去コーディングを実装しており、Facebook の Tectonic Filesystem と多くの類似点があります。
オブジェクト ストアに加えて、オプションの Filer はディレクトリと POSIX 属性をサポートできます。 Filer は、カスタマイズ可能なメタデータ ストア (例: MySql、Postgres、Redis、Cassandra、HBase、Mongodb、Elastic Search、LevelDB、RocksDB、Sqlite、MemSql、TiDB、Etcd、CockroachDB、YDB など) を備えた別個の線形スケーラブルなステートレス サーバーです。
分散キー値ストアの場合、大きな値を SeaweedFS にオフロードできます。 SeaweedFS は、高速なアクセス速度と直線的に拡張可能な容量を備えているため、分散型 Key-Large-Value ストアとして機能します。
SeaweedFS はクラウドと透過的に統合できます。ローカル クラスター上のホット データと O(1) アクセス時間のクラウド上のウォーム データにより、SeaweedFS は高速なローカル アクセス時間と柔軟なクラウド ストレージ容量の両方を実現できます。さらに、クラウド ストレージ アクセス API のコストも最小限に抑えられます。直接クラウドストレージより速くて安い！
目次に戻る
目次に戻る
目次に戻る
デフォルトでは、マスター ノードはポート 9333 で実行され、ボリューム ノードはポート 8080 で実行されます。1 つのマスター ノードと、ポート 8080 および 8081 で 2 つのボリューム ノードを起動しましょう。理想的には、これらは異なるマシンから起動する必要があります。例としてローカルホストを使用します。
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 &
ファイルをアップロードするには: まず、HTTP POST、PUT、または GET リクエストを/dir/assignに送信して、 fidとボリューム サーバー URL を取得します。
> curl http://localhost:9333/dir/assign
{"count":1,"fid":"3,01637037d6","url":"127.0.0.1:8080","publicUrl":"localhost:8080"}
次に、ファイルのコンテンツを保存するには、HTTP マルチパート POST リクエストを応答からurl + '/' + fidに送信します。
> curl -F file=@/home/chris/myphoto.jpg http://127.0.0.1:8080/3,01637037d6
{"name":"myphoto.jpg","size":43234,"eTag":"1cc0118e"}
更新するには、更新されたファイルの内容を含む別の POST リクエストを送信します。
削除するには、HTTP DELETE リクエストを同じurl + '/' + fid URL に送信します。
> curl -X DELETE http://127.0.0.1:8080/3,01637037d6
これで、 fid (この場合は 3,01637037d6) をデータベース フィールドに保存できます。
先頭の数字 3 はボリューム ID を表します。カンマの後には、1 つのファイル キー 01 とファイル Cookie 637037d6 が続きます。
ボリューム ID は符号なし 32 ビット整数です。ファイルキーは符号なしの 64 ビット整数です。ファイル Cookie は符号なし 32 ビット整数であり、URL の推測を防ぐために使用されます。
ファイル キーとファイル Cookie は両方とも 16 進数でコード化されます。 <volume id, file key, file cookie> タプルを独自の形式で保存することも、単純にfidを文字列として保存することもできます。
文字列として保存する場合、理論的には 8+1+16+8=33 バイトが必要になります。ほとんどの用途では 2^32 ボリュームは必要ないため、十分ではないにしても、char(33) で十分です。
スペースが本当に心配な場合は、ファイル ID を独自の形式で保存できます。ボリューム ID には 4 バイトの整数が 1 つ、ファイル キーには 8 バイトの長さの数値が、ファイル Cookie には 4 バイトの整数が必要です。したがって、16 バイトあれば十分です。
URL をレンダリングする方法の例を次に示します。
まず、ファイルの volumeId でボリューム サーバーの URL を検索します。
> curl http://localhost:9333/dir/lookup?volumeId=3
{"volumeId":"3","locations":[{"publicUrl":"localhost:8080","url":"localhost:8080"}]}
(通常は) ボリューム サーバーの数はそれほど多くなく、ボリュームは頻繁に移動しないため、ほとんどの場合、結果をキャッシュできます。レプリケーションのタイプに応じて、1 つのボリュームに複数のレプリカの場所を持つことができます。ランダムに 1 か所を選んで読んでください。
これで、パブリック URL を取得したり、URL をレンダリングしたり、URL 経由でボリューム サーバーから直接読み取ることができます。
http://localhost:8080/3,01637037d6.jpg
ここでファイル拡張子「.jpg」を追加していることに注意してください。これはオプションであり、クライアントがファイルのコンテンツ タイプを指定する方法の 1 つにすぎません。
より適切な 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: 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
レプリケーションの詳細については、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 バイトのみを使用するため、すべてのファイル アクセスでメモリからファイル メタデータを読み取ることができ、実際にファイル データを読み取るために必要なディスク操作は 1 回だけです。
比較のために、Linux の xfs i ノード構造が 536 バイトであると考えてください。
アーキテクチャはかなりシンプルです。実際のデータはストレージ ノード上のボリュームに保存されます。 1 つのボリューム サーバーに複数のボリュームを含めることができ、基本認証による読み取りアクセスと書き込みアクセスの両方をサポートできます。
すべてのボリュームはマスター サーバーによって管理されます。マスターサーバーには、ボリューム ID とボリュームサーバーのマッピングが含まれています。これはかなり静的な情報なので、簡単にキャッシュできます。
書き込みリクエストのたびに、マスター サーバーはファイル キーも生成します。このファイル キーは、増加する 64 ビットの符号なし整数です。通常、書き込みリクエストは読み取りリクエストほど頻繁ではないため、1 つのマスター サーバーで同時実行性を適切に処理できる必要があります。
クライアントが書き込みリクエストを送信すると、マスター サーバーはファイルの (ボリューム ID、ファイル キー、ファイル Cookie、ボリューム ノード URL) を返します。次に、クライアントはボリューム ノードに接続し、ファイルのコンテンツを POST します。
クライアントは、(ボリューム ID、ファイル キー、ファイル Cookie) に基づいてファイルを読み取る必要がある場合、ボリューム ID によってマスター サーバーに (ボリューム ノード URL、ボリューム ノード パブリック URL) を要求するか、これをキャッシュから取得します。その後、クライアントはコンテンツを GET することも、Web ページ上に URL をレンダリングしてブラウザーにコンテンツをフェッチさせることもできます。
書き込み/読み取りプロセスの詳細については、例を参照してください。
現在の実装では、各ボリュームは 32 ギビバイト (32GiB または 8x2^32 バイト) を保持できます。これは、コンテンツを 8 バイトに揃えるためです。 2 行のコードを変更することで、アライメントによる無駄なパディング スペースを犠牲にして、これを 64 GiB、または 128 GiB、あるいはそれ以上に簡単に増やすことができます。
4 ギビバイト (4GiB または 2^32 バイト) のボリュームが存在できます。したがって、システムの合計サイズは 8 x 4GiB x 4GiB、つまり 128 exbibyte (128EiB または 2^67 バイト) になります。
個々のファイル サイズはボリューム サイズに制限されます。
ボリューム サーバーに保存されているすべてのファイル メタ情報は、ディスクにアクセスせずにメモリから読み取ることができます。各ファイルは、<64 ビット キー、32 ビット オフセット、32 ビット サイズ> の 16 バイトのマップ エントリのみを受け取ります。もちろん、各マップ エントリには、マップに対する独自のスペース コストがかかります。しかし、通常はメモリがなくなる前にディスク容量が足りなくなります。
ローカル ボリューム サーバーははるかに高速ですが、クラウド ストレージには柔軟な容量があり、頻繁にアクセスされなければ実際にはコスト効率が高くなります (通常、アップロードは無料ですが、アクセスには比較的コストがかかります)。追加専用構造と O(1) アクセス時間により、SeaweedFS はウォーム データをクラウドにオフロードすることで、ローカル ストレージとクラウド ストレージの両方を活用できます。
通常、ホット データは新しく、ウォーム データは古いです。 SeaweedFS は、新しく作成したボリュームをローカル サーバーに配置し、オプションで古いボリュームをクラウドにアップロードします。古いデータへのアクセス頻度が低い場合、限られたローカル サーバーで文字通り無制限の容量が得られますが、新しいデータについては依然として高速です。
O(1) アクセス時間により、ネットワーク遅延コストは最小限に抑えられます。
ホット/ウォーム データが 20/80 に分割され、サーバーが 20 台の場合、サーバー 100 台のストレージ容量を実現できます。 80% のコスト削減になります。または、80 台のサーバーを再利用して新しいデータを保存し、5 倍のストレージ スループットを得ることができます。
目次に戻る
他の分散ファイル システムのほとんどは、必要以上に複雑に思えます。
SeaweedFS は、セットアップと操作の両方において高速かつシンプルであることを目的としています。ここまで来て仕組みが分からなかったら失敗です！質問がある場合は問題を提起するか、説明を加えてこのファイルを更新してください。
SeaweedFS は常に前進しています。他のシステムでも同様です。こうした比較はすぐに古くなってしまう可能性があります。最新情報を維持するためにご協力ください。
目次に戻る
HDFS は各ファイルに対してチャンク アプローチを使用し、大きなファイルの保存に最適です。
SeaweedFS は、比較的小さなファイルを迅速かつ同時に処理するのに最適です。
SeaweedFS は、非常に大きなファイルを管理可能なデータ チャンクに分割して保存し、データ チャンクのファイル ID をメタ チャンクに保存することもできます。これは「ウィード アップロード/ダウンロード」ツールによって管理され、ウィード マスターまたはボリューム サーバーはこれについて認識しません。
目次に戻る
アーキテクチャはほとんど同じです。 SeaweedFS は、シンプルでフラットなアーキテクチャにより、ファイルを高速に保存および読み取りすることを目的としています。主な違いは次のとおりです。
| システム | ファイルのメタデータ | 読み取られたファイルの内容 | POSIX | REST API | 多数の小さなファイル向けに最適化 |
|---|---|---|---|---|---|
| 海藻FS | ボリューム ID のルックアップ、キャッシュ可能 | O(1) ディスクシーク | はい | はい | |
| SeaweedFS ファイラー | 直線的に拡張可能、カスタマイズ可能 | O(1) ディスクシーク | ヒューズ | はい | はい |
| グルスターFS | ハッシュ化 | ヒューズ、NFS | |||
| セフ | ハッシュ + ルール | ヒューズ | はい | ||
| ムースFS | 記憶の中で | ヒューズ | いいえ | ||
| MinIO | ファイルごとに個別のメタファイル | はい | いいえ |
目次に戻る
GlusterFS は、ディレクトリとコンテンツの両方のファイルを「ブリック」と呼ばれる構成可能なボリュームに保存します。
GlusterFS はパスとファイル名を ID にハッシュし、仮想ボリュームに割り当ててから、「ブリック」にマッピングします。
目次に戻る
MooseFS は、小さいファイルの問題を無視することを選択します。 moosefs 3.0 マニュアルによると、「小さいファイルでも 64KiB に加えて、チェックサムの 4KiB とヘッダー用の 1KiB を占有します」。これは、「当初は、非常に大きなファイルを大量 (数千など) 保持するように設計されていたため」です。
MooseFS マスター サーバーは、すべてのメタデータをメモリ内に保持します。 HDFS ネームノードと同じ問題。
目次に戻る
Ceph は SeaweedFS と同様にキー -> BLOB ストアとしてセットアップできます。これは、その上にレイヤーをサポートする必要があるため、はるかに複雑です。詳しい比較はこちら
SeaweedFS には空きボリュームを検索する集中マスター グループがあり、Ceph はハッシュ サーバーとメタデータ サーバーを使用してオブジェクトを見つけます。一元化されたマスターがあると、コーディングと管理が簡単になります。
Ceph は、SeaweedFS と同様、オブジェクト ストア RADOS に基づいています。 Ceph はかなり複雑で、さまざまなレビューがあります。
Ceph は CRUSH ハッシュを使用してデータ配置を自動的に管理するため、データを効率的に見つけることができます。ただし、データは CRUSH アルゴリズムに従って配置する必要があります。構成が間違っていると、データ損失が発生する可能性があります。容量を増やすために新しいサーバーを追加するなど、トポロジの変更により、CRUSH アルゴリズムに適合させるために高い IO コストを伴うデータ移行が発生します。 SeaweedFS は、書き込み可能なボリュームにデータを割り当てることによってデータを配置します。 1 つのボリュームへの書き込みが失敗した場合は、別のボリュームを選択して書き込みます。ボリュームを追加するのも非常に簡単です。
SeaweedFS は小さなファイル用に最適化されています。小さなファイルは、ファイル間に最大 8 バイトの未使用バイトが存在する、1 つの連続したコンテンツ ブロックとして保存されます。小さいファイルへのアクセスは O(1) ディスク読み取りです。
SeaweedFS Filer は、MySql、Postgres、Sqlite、Mongodb、Redis、Elastic Search、Cassandra、HBase、MemSql、TiDB、CockroachCB、Etcd、YDB などの既製ストアを使用してファイル ディレクトリを管理します。これらのストアは実績があり、拡張性があり、管理が容易です。
| 海藻FS | Ceph に匹敵する | アドバンテージ |
|---|---|---|
| マスター | データシート | より単純な |
| 音量 | OSD | 小さなファイル用に最適化 |
| ファイラー | セフFS | 線形スケーラブル、カスタマイズ可能、O(1) または O(logN) |
目次に戻る
MinIO は AWS S3 に厳密に従っており、S3 API のテストに最適です。 SeaweedFS は優れた UI、ポリシー、バージョン管理などを備えています。SeaweedFS はここで追いつくことを目指しています。後で SeaweedFS の前にゲートウェイとして MinIO を配置することも可能です。
MinIO メタデータは単純なファイル内にあります。ファイルの書き込みごとに、対応するメタ ファイルへの追加の書き込みが発生します。
MinIO には、多数の小さなファイルに対する最適化がありません。ファイルはそのままローカル ディスクに保存されるだけです。さらに、イレイジャー コーディング用の追加のメタ ファイルとシャードは、LOSF 問題を増幅させるだけです。
MinIO は 1 つのファイルを読み取るために複数のディスク IO を備えています。 SeaweedFS は、Erasure Code ファイルの場合でも、O(1) のディスク読み取りを行います。
MinIO はフルタイム消去コーディングを備えています。 SeaweedFS は高速化のためにホット データのレプリケーションを使用し、オプションでウォーム データに消去コーディングを適用します。
MinIO には POSIX のような API サポートがありません。
MinIO にはストレージ レイアウトに関する特定の要件があります。容量の調整が柔軟ではありません。 SeaweedFS では、マスターを指すボリューム サーバーを 1 つ起動するだけです。それだけです。
これは超エキサイティングなプロジェクトです！そして私たちにはヘルパーとサポートが必要です！
目次に戻る
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 に優しいです。削除と圧縮はバックグラウンドでボリューム レベルで実行されるため、読み取りが遅くなったり、断片化が発生したりすることはありません。
目次に戻る
私自身の非科学的な単一マシンの結果は、ソリッド ステート ディスク、CPU: 1 Intel Core i7 2.6GHz を搭載した Mac Book 上で実行されました。
100万個の1KBファイルを書き込みます:
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
100 万個のファイルをランダムに読み取ります。
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.
セグメント化されたリクエスト統計を表示するには、--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.
目次に戻る
Apache License バージョン 2.0 (「ライセンス」) に基づいてライセンスされています。ライセンスに準拠する場合を除き、このファイルを使用することはできません。ライセンスのコピーは次の場所で入手できます。
http://www.apache.org/licenses/LICENSE-2.0
適用される法律で義務付けられている場合または書面による同意がない限り、ライセンスに基づいて配布されるソフトウェアは、明示または黙示を問わず、いかなる種類の保証や条件もなく、「現状のまま」で配布されます。ライセンスに基づく許可と制限を規定する特定の言語については、ライセンスを参照してください。
このページのテキストは、Creative Commons Attribution-Sharealike 3.0 Unported License および GNU Free Documentation License (バージョン管理されておらず、不変セクション、表紙のテキスト、または裏表紙のテキストがない) の条件に基づいて変更および再利用できます。
目次に戻る
