このイベントはどのように重要ですか？ その瞬間まで、nginxはネットワークで作業している場合にのみ非ブロックモードを使用していました。ファイルでの作業はワークフローをブロックしていました。 これは何につながりましたか？ すべてがOSキャッシュにない多くの異なるコンテンツ（写真ホスティングなど）がある場合-遅かれ早かれ、50、150、200のすべてのプロセスがディスク操作を待機し、新しいクライアントにサービスを提供できません-必要なコンテンツが返されてもファイルキャッシュから、またはバックエンドからのリクエスト。
これにどう対処するのですか？
- 最初の方法は、ワークプロセスの数を増やすことです。 しかし、どれだけ多くても、全員がディスクにロックされる可能性は常にあります。
- 2番目の方法は、異なるnginx'amiでダイナミクスとスタティックを配布することです。 ただし、人気のある静的データのリクエストは、早い段階で処理されません。
- 2番目のスキームをさらに複雑にする-「人気のあるファイル」の概念を定義し、それらを個別に配布する。 ただし、OSキャッシュは常に独自の人気リストよりも効率的に機能します（実際、これはキャッシュのロジックの繰り返しです）
少数のワークプロセスを使用して、すべてを非ブロックモードで配布する新しい方法が登場しました。 テストでは、ファイル/画像ホスティングの負荷をエミュレートします-多数の比較的小さなファイルを返します。 ディスクはランダムシーク速度に依存します。
試験方法：
- テストサーバー-OC FreeBSD 7.2安定版、2xSATA 150GB 7200 rpm raid1、2GB RAM
- ファイルキャッシュのメモリ量〜1.2 GB
- テストファイルのボリュームは〜2.5 gb、各ファイルは8〜16 kb、nginxのsend-bufferは16 kbに設定されます。
- nginxバージョン0.8.19
- テストサーバー-ネットワーク経由で接続、チャネル帯域幅〜20 mbit
- ロードはabユーティリティによって作成され、fastcgiスクリプトを使用してランダムなファイル名を生成し、X-Accel-Redirectを返しました
結論：AIOを使用すると、使用するディスクのシークレートよりも大幅に高い300 rpsを達成できたという事実から判断すると、FreeBSDコアは内部のAIOを経由するリクエストを並べ替えることができます。これにより、大きなキャッシュを備えた「インテリジェントな」RAIDコントローラーがない場合に大幅なゲインが得られます 従来の方法を使用する場合、多数のワークプロセスがすべてディスクに送られると、パフォーマンスに悪影響を与えるだけです。
PS：テクニックに関するいくつかのコメント。 ランダムなファイル名を生成する速度は十分で、リクエストに0.5ミリ秒未満を追加します（より正確に測定する必要はありませんでした。この速度は達成できませんでした）。 おそらく、多数のスレッドでaioを使用したテストでは、チャネルの上限に達しました。 各テストの所要時間は2分です。
PPS：LinuxでのAIOの動作はテストされていません。結果は方向によって異なる場合があります。