しかし、その記事には欠陥があります-テストでは、アクセスは1つのファイルに行き、同時にファイルはnginxまたはファイルシステムレベルでキャッシュされるため、GridFSと比較してギャップが生じます。 はい、新鮮なGridFSをチェックできてうれしいです。結局3年が経ちました。
そのため、異なるファイル名を使用して、独自のテストを実施することにしました。
52,000のファイルがあります。映画のポスター、合計2GBの容量、平均的な画像の重さは40kbです。 ext4でファイルをコピーし、GridFSでコピーします。
1コアの512MB仮想マシン。 Ubuntuサーバー12.04 LTS 64ビット、Nginx / 1.4.1設定が標準です。
このテストは低コストのサーバー向けに設計されており、強力なサーバー向けには結果が異なります。
ファイルをアップロードする方法：
1）Nginx-統計
2）nginxを介したイベント
3）nginx経由の2 x Gevent（バランス）
4）直接イベント
5）nginx経由のイベント（unixソケット）
ポイント2〜5では、HTTPサーバーがPython + Geventで使用され、GridFSからファイルを提供しました。
ロードの方法：
1）ol、t2-1つのURL、2つのスレッドへのアクセス
2）ol、t10-1つのURLへのアクセス、10スレッド
3）t2-異なるURLへのアクセス、2スレッド
4）t10-別のURLへのアクセス、10スレッド
詳細：
*すべてのテストは、表の平均値である3回実行されました。
*すべてのテストで異なるURLへのアクセスは同じリンクのリストで行われ、リンクにはファイル識別子が含まれます（GridFSでは、検索は識別子による）
* 1つのURLにアクセスするテストでは、ファイルサイズは13.5 kbです。
* geventを介してアップロードすると、最後のファイルがキャッシュされるため、単一のURLにアクセスするテストではGridFSにアクセスせず、実際にはPythonからのデータ出力の速度が測定されます。
*「1リンク」テストは、主にクライアントの制限を決定するために行われます。
クライアントはPythonで書かれており、結果から判断すると、その容量は1秒あたり最低1450のリクエストに十分です。 スレッドを増やすか、複数のプロセスとして起動しても、パフォーマンスはあまり向上しません。 ここから、サーバーがボトルネックであったと判断できます。これはテストに必要です。
その結果、少なくとも小規模サーバーでは、GridFSのパフォーマンスが以前考えられていたほど低くないという情報を受け取りました。
その他のアイデア：
* nginx-gridfsを試す
* uwsgi-gridfs
* yieldによるファイルのアップロード
*他のプロキシサーバーを試す
*他のFSを試してください（ZFS？）
また、強力なサーバーでテストする予定です。
スクリプトソース