リターンを「改善する」ためのsendfileまたはaioの設定について説明した記事があります。
Habréでは、サイトの頭脳からの問題を最小限に抑えるためにproxy_storeをproxy_cacheに設定することについて読むべきことがあります。
QAに戻ると、たとえば、 画像のキャッシングについて疑問が生じることがあります。
なんでこんなナンセンスなの！ -経験豊富なユーザーは言う-OSはファイルをキャッシュする方法よりもあなたをよく知っている！ 最新のOS、より正確にはFSのキャッシュとプリフェッチにより、問題はありません！ キャッシュや人気のある素材のリストを作成する理由は何ですか？...
有害な「しかし」たった1つがあります-nginxランタイム（一般的にLinux）では、「 ファイル 」と一般的に「ファイルシステム」 の概念は単なる概念です。
かつて、私がsshfsを介してサーバーをマウントし、1つのスクリプトを更新すると、魔法が起こりました。
1.各ページにはさらに4つの写真があります。
2.サーバーが停止しています。
対処方法-写真はglusterFSに保存されていました。 フルヒューズが来ました。
GlusterFSは、FUSEインターフェースと同様に、パフォーマンスを大きく消耗しますが、それだけの価値はあります。
最初は、1つのサーバーがありました。 次に2つ、2つ目は1つ目からnfsまでwwwをマウントしました。 その後、3、4。
あまり信頼できませんが、 歴史的にそうです。 状況を保存するには、完全に透過的なシステム、nfsのインプレース置換が必要でした。 クラスターFS。
現在、すべてのサーバーがRAID 10を使用しており、1年半操作した後、数回クラッシュしました。 含む。 Glusterは新しいハードウェア上でFSのコピーを静かに作成し、すべてが機能し続けました。 Glasterは彼の仕事を知っています。
しかし実際には、話は少し間違っていました。
理由は異なりますが、問題の解決策は同じです。
「 歴史的に 」という事実ほど悪いことはありません。
そして、私のプロジェクトの1つである、「歴史的に開発された」状況で、phpが写真を提供します。
かつては、さまざまなACL、サイズ変更、透かしを含むファイルローダーを作成する必要がありました。 それはほぼ10年前です。 メカニズムは定着しており、それ以降変更されていません。
現在、このような問題を解決するための多くの専門的なソリューションがあります（ 楕円 、 バックパックなど、さらに良いことに、CDN）。 しかし、移行に何ヶ月も費やしたくありません。 仕事ではなく眠りたい。
はい、PHPの読み取りは原則として悪くありません。 しかし、それには限界があります。
しかし、ブレーキバックエンドの問題は解決されました
Habr、ソリューションオプション-proxy_storeおよびproxy_cacheをもう一度求められました 。
しかし、proxy_storeは使用できません。保存する場所がなく、proxy_cacheにも問題があります。
「しかし」という大きなことが1つあります。何年も前に、私はすでにファイルのアップロードパフォーマンスに直面していました。
X-Accel-Redirect。
問題-応答ではなくコマンドである場合、nginxはプロキシからの応答をキャッシュできません。 X-Accel-Redirect-キャッシュされていません 。
抜け道はありませんか？
元の問題は修正されました
トピックの最初に戻ります。
今回は、「スマート」バックエンドの介入なしで静的を与える必要があります。 静的ですが、glusterfsを使用します。
静的キャッシュのディレクティブはありません-それらは提供されていません。 OS自体は馬鹿ではないと考えられています。 静的には、open_file_cacheとファイル転送自体の構成（sendfile / aioおよびcompany）のみがあります。
どうする
タスクを複雑にし、他のコードに変更を加えることなく、nginxのみを使用して問題を解決しようとします。
通常の構成
# Static files location location ~* ^.+\.(jpg|jpeg|gif|png|ico|css|js|swf|txt|ico)$ { root /var/www/kashey; }
パッチを適用した構成
Nginxはそれ自体でproxy_passを実行し、結果をキャッシュします。 おそらくここでfcgiを使用できますが、より視覚的です。
# Static files location location ~* ^.+\.(jpg|jpeg|gif|png|ico|css|js|swf|txt|ico)$ { set $dopass 1; proxy_set_header Host $host; # "" - if ($http_fiberpass) { root /var/www/kashey; # proxy_pass set $dopass 0; break; # break } # , proxy_cache_valid proxy_cache static_cache; # "" proxy_set_header fiberpass "nginx"; if ($dopass) { # . proxy_pass http://127.0.0.1:80; } }
そして魔法はありません。
X-Accel-Redirectの場合、スキームは次のとおりです。
1.リクエストを受信したnginx
2.残念ながら、リクエストは完全かつ本物です。
3.プロキシに転送する
4.応答を受信し、ファイルを提供します
5.回答はキャッシュされます
6. ???
7.利益
通常の静的の場合、それはより困難です-ルートは実行を終了せず、ブレークして戻りも機能しません。 プロキシ設定を条件ブロック内に含めることはできません。
それは何を与えますか？
apacheを使用したX-Accel-Redirectでは、リクエストシャフトは削除されます。 ビジーなシステムでは、差は50倍になることがあります。
しかし、これは理解できます-PHP自体、さらにはApacheを介したものは、最も反応的なソリューションではありません。
Latensyリクエストは40ミリ秒未満で、個人的には成功しませんでした（合計時間php + gluster）。
proxy_cacheでオプションを使用する場合、戻りの速度はstaticの戻りの速度に等しくなります。
静力学はどうですか？
グルースターでの反動-13ms-これは、キャッシュのないシステムの通常の時間です。
キャッシュからの戻り-1ms-これは素晴らしいです。
考慮することが重要です-サーバーはドイツにあり、クライアントはロシアにあります。
サイトへの通常のpingは60〜100ミリ秒です。
クライアントにとって、加速はほとんど目立ちません。
しかし、それはサーバーに顕著です。
1.サーバーの負荷が減少しました。これには、オウムのLoad averageおよびsoft-irqが含まれます。
2.サーバー間のトラフィックを削減します（WORM（Write Once Read Manyボリューム）を有効にすることもできますが、これはもはや「透過的」ではありません）。
3.すべてが少し速くなり始めました。
その結果、クライアントの反応率を10％低下させた作業は、静的応答の10倍の加速の結果でした。 これにより、サーバーの全体的な負荷が約20回に1回減少しました。
残念なことに、逆の声明も真実です-どんなに頑張っても、クライアントは気付かないかもしれません。
PS：多くの使い慣れたシステム管理者は、そのようなスキームの可能性についても考えていませんでした。 キャッシング/プロキシを許可しません-つまり不可能です。
優れたプログラマーは常に優れたシステム管理者であるとは限らず、システム管理者は通常プログラマーではありません。
本物のヒーローは、常に自転車で走り回ります。
PPS：ところで、私はシステム管理者ではありません。 そして、おそらく、彼はすべてを間違っていた。