親愛なるhabradevelopers！
あなたの多くは、優れたnginx軽量Webサーバーを知っています。
memcachedの操作方法を知っている人もいます。
しかし、 SSIがそれとどう関係しているのか、それをnginxおよびmemcachedと組み合わせてどのように使用できるのかを認識しているのは少数です。
ご存知のように、新しいものは忘れられた古いものです。 指定されたツールとテクノロジーのそれぞれは、おそらくあなたに知られています。 このすべてを1つの山にダンプする方法と理由についてお話したいと思います:)
nginx
クラシックスキームでは、nginxは、Apacheなどの1つ以上のサーバーの前でロードバランサーまたはリバースプロキシとして使用されます。
nginxは、画像、CSS、JSファイルなどの静的リソースを提供します。 彼は動的ページへのリクエストをApache / PHPに渡し、Apache / PHPはそれらを個別に処理して結果を返します。
ハブでnginxに関する記事を検索したが、この「古典的な」スキームの動作の詳細な説明は見つかりませんでしたが、トピックから気を散らしたくないので、 Googleをもっと深く掘り下げたい人にアドバイスします-ネットワークにはたくさんの情報とチュートリアルがあります。
memcached
nginxは、 ngx_http_memcached_moduleモジュールを使用してmemcachedと連携できます。
nginxは、特定のURLへのリクエストを受信すると、まずそのURLのリクエスト結果がキャッシュにあるかどうかを確認します。 存在する場合はキャッシュされたページをそのまま返し、存在しない場合はリクエスト処理をApache / PHPに渡します。 PHPは、リクエストを受信した後、レスポンスを準備し、memcachedに保存して、ユーザーに表示します。 したがって、同じURLでの次のリクエストで、nginx自体がキャッシュ内で結果を見つけてユーザーに返し、Apache / PHPへのリソース集約的な呼び出しをバイパスします。
理論的には、すべてがシンプルで便利ですが、実際にはそのようなキャッシュの使用は非常に制限されています。
habrのメインページをキャッシュしたいとしましょう:)
右上隅に認証ブロック（ログイン/登録、または現在のユーザーに関する一般情報）、「ブックマーク」（すべて、集合、個人...）、クリップされた記事のフィード、タグクラウドなどが表示されます。
ページ上のすべてのブロックは、静的と動的に分けることができます。 条件付き-実際にはすべてのブロックは動的ですが、一部はキャッシュできますが、一部はキャッシュできないためです。 許可されていないユーザーのメインページをキャッシュし、許可されたユーザーが同じURLでアクセスするとどうなるか、自分で考えてみてください。 そうです、右上隅にログインまたは登録の招待状が表示され、少なくとも驚かれることでしょう。
どうする？ 1つのオプションは、ページ全体をキャッシュしないことです！ キャッシングから動的ブロックを除外する機能があります。 そして、彼らはこれで私たちを助けます...
SSI、またはサーバー側インクルード
他の誰かが覚えていれば、JSP、ASP、PHP、およびRoRを備えた他のDjangoのずっと前に、そのようなテクノロジーが使用されていました:)
その意味は、通常のHTMLページがクライアントに送信される前にサーバーで特定の方法で処理されたことです。 たとえば、通常のincludeディレクティブは次のようになりました。
<!--#include file="header.html"-->
ここでは、この特定のディレクティブにのみ関心がありますが、ファイルを含めるのではなく、仮想を含めます。 それらは、インクルードファイルが代わりにファイルの内容を挿入し、仮想を含むという点で異なります-指定されたURLでの仮想クエリの結果。 nginxでは、 ngx_http_ssi_moduleモジュールが計画の実現に役立ちます。
Habrのメインページを使用した例に戻り、ページをそのままキャッシュに配置します。承認ブロックをこのインクルードに置き換えるだけです。
<!-- #include virtual="/auth" -->
次に、nginxがキャッシュからこのページを受け取ると、クライアントに渡す前にすべてのSSI命令を処理する必要があります。 したがって、nginxはURL "/ auth"で仮想リクエストを実行し、キャッシュ内でこのURLの結果を見つけることなく、リクエストをApache / PHPに転送します。 現在、PHPのタスクは、現在のユーザーの承認を確認し、ユーザーが承認されているかどうかに応じて、承認ブロックのHTMLコードを返すことです。
Apache / PHPから結果を受け取った後、nginxはincludeディレクティブの場所に結果を挿入し、ページをクライアントに返します。 したがって、承認されたクライアントと承認されていないクライアントには異なるページが表示され、そのコンテンツは引き続きキャッシュされ、貧しいHabrサーバーは各リクエストに対してクリップされた記事のフィードを受信したり、タグクラウドを生成したりする必要はありません -単純な承認ブロックのみ;）
練習する
このアイデアを実装する実用的な例をすぐに説明したかったのですが、記事はかなり大きなものになりました。サーバー構成の説明とPHP＆Zend Frameworkの例を使用して、実用的な部分を別に作成する方が良いでしょう。
そして、最もせっかちなhabradevelopersはすでにこのトピックを深く掘り下げるためのすべてのリンクを持っています:)
PS：正直なところ、実際のところ、私は残念ながらそのようなキャッシングへのアプローチを持っていません。 完成したコードのスケッチはほんの少ししかありませんが、一見すると非常に機能的です。 集合的な心がボトルネックや潜在的な問題を促した場合-私は非常に感謝します。 ご清聴ありがとうございました！