Personal tools
You are here: Home → Misc → Plone Misc → CacheFuに同梱されているドキュメント「audience.rest」
 

CacheFuに同梱されているドキュメント「audience.rest」

CacheFuに同梱されているドキュメント（cachefu/CacheSetup/doc/audience.rest）の超訳です。

CacheFuはPloneのサイトがより速くなるようにするテクノロジーのセットです。変更が加えられたコンテンツやナビゲーションもちゃんと変更が反映されて表示されます。

これはいくつかの既存のプロダクトにたくさんのコンフィギュレーションを加えて行われます。たいていのサイトは、ほとんど（あるいは全く）設定の変更を加えずに、劇的なパフォーマンスの向上を経験する事でしょう。そして、さらにチューニングすることで、さらなるパフォーマンス向上を期待できます。

キャッシングへの招待

Ploneのようなステキなプログラムはちょっと遅いでしょう。これは別に開発者の過失というわけではなくて、Ploneがページのリクエストを受けるときに、あなたにいろんなことをしてあげている、その機能の副作用なのです。

例えば「newsitems-project-a」というページのリクエストがあった場合を想像してみてください。Ploneがしなければならないことは：

  • そのユーザがログインしているかどうかをチェックし、もしそうであれば、そのログインが正しいかどうかをチェックする
  • オブジェクトデータベースから当該オブジェクトを見つける
  • そのユーザが当該オブジェクトに対する権限を持っているかどうかをチェックする
  • ページテンプレートをスキン化する
  • 要求されたロジックを実行する（例えばカレンダーポートレットはカレンダーに表示するものを探さなくてはならない）
  • そのユーザに関する情報を加える（名前を表示したり、個人設定を適用したり、などなど）
  • 必要なJavaScriptやCSSを決める
  • 動的なナビゲーションツリーなどを生成する
  • どのポートレットを表示するか考えて、それらを表示する
  • もっともっといろいろすることが…

これらのいろいろなチェックや動的な生成は、Ploneをリッチで使いやすいものにしてくれるという意味で非常によいことですが、これはPlone の外から見れば、短い時間ではウェブページをあまり表示できないと言う事になります。あまりトラフィックのないサイトでは許容できることかもしれませんが、もっとトラフィックの多いサイトではページを行き来するだけで何秒も待たされる事になり、ユーザは「遅いなぁ」と感じることになります。

これを解決する一つの方法は、キャッシュすることです。Zope/Ploneや他のプログラムに、「この部分はいつも生成して表示する必要はない」ということを教えて、その部分に関しては以前生成したものを使わせるということです。

うまくやればキャッシングはとても役に立ちます。誰も気づかないうちにサイトはより速く動くようになります。ただし正しく設定していないと、更新されるべき部分が古いまま表示されたりして（例えば新しいニュースを投稿したのにそれが表示されないなど）、ユーザはフラストレーションを感じるでしょう。

まぁ、ある程度の「最新でない感じ」はパフォーマンスとのトレードオフの関係で許容しなければならないでしょう。たとえば天気を表示するポートレットを使っているときに、たいていの人は1分間に600回もお天気サーバにアクセスするなんてことはしたくないはずです。5分ごととか、5時間ごととか、時間は何でもイイですが、とにかくその辺で妥協するでしょうし、ちょびっと古い情報であってもパフォーマンスを考えればそれでOKでしょう。

CacheFuは（ほんの一部の例外を除いて）こういった妥協をさせません。あなたのサーバは今までより少し働く事になるかもしれませんが、 CacheFuがあなたに最新のコンテンツを届ける事を信じてください。サイトをよりコントロールしたい人にとっては、このドキュメントが助けになるでしょう。

Zopeの内側でのキャッシング
Zopeの内側でキャッシュされるデータは、Zopeが直接生成しているわけですが、これは常に時間を消費するようなものではありません。一般にZope内のキャッシングはあまりスピードアップに後見するわけではありませんが、コンテンツが変更された場合には、Zope/Ploneはこの変更を認識しやすく、結果として新しいコンテンツを表示しやすいと言う事になります
 プロクシサーバでのキャッシング
 このタイプのプログラムは、ブラウザとZopeの中間に位置します。たとえば「Jane」というユーザがページをリクエストしたときには、彼女のリクエストはプロクシサーバに届けられます。プロクシサーバはZopeにこのコンテンツを生成させるかどうかを決めます。ほとんどのケースでは、プロクシサーバはこの情報をすでに持っていて、コンテンツをJaneに返します。プロクシサーバはこういう動きをすることに最適化されているわけですから、この動作はとても速いです。プロクシサーバが直接Janeに送る事のできないコンテンツに関してはZope にリクエストがいきます。いくつかのケースではプロクシサーバはこのコンテンツについて知り、そのうち直接送る事ができるようになるでしょう。オープンソースのプロクシサーバとしてとても有名なのはSquidです。そしてCacheFuはSquidと共に機能するように最適化されています。より一般的で拡張性に富んだウェブサーバであるApacheもキャッシングをすることができます。ただしApacheはSquidが持っている機能すべてを持っているわけではありません。特にキャッシュしたコンテンツの消去機能がありません。Apacheは特定のものに対するプロクシキャッシュとして利用することはできますが、CacheFuがSquidと同じくらいApacheの機能を有効活用することはできないでしょう。というわけで、トラフィックの多いサイトではSquidを利用するとよいでしょう。もちろんトラフィックの少ないサイトでも効果はありますが、劇的な効果を生むわけではありませんし、新しいソフトを導入する理由にはならないかもしれません。
 ブラウザでのキャッシング
 ほとんどすべてのブラウザはウェブページや画像をキャッシングすることができます。ブラウザがキャッシングをすると、同じページや画像をブラウザ自身が返す事ができるためネットワークを経由する必要がなくなり、明らかに反応は速くなります。Zopeやプロクシサーバがリクエストがあったことを知る事がないようなケースもあるでしょう。しかしブラウザ側で行われる一般的な技術は、すべてのウェブブラウザが扱えるわけではありませんし、CacheFuがキャッシュするコンテンツも「最新状態ではない」というリスクなしにブラウザが扱えるものではありません。

 以上のようなキャッシングに加えて、他にも4つほどキャッシングされうる場所があります。

ZSQLメソッドやデータベースなどでのキャッシング
Plone内からリレーショナルデータベースに接続するような場合には、ZSQLメソッドの結果をキャッシュすることができます。たとえばSQLメソッドが毎秒呼ばれていたようなアプリケーションで、5分に一度だけクエリするようなことも可能です。同様にいくつかのデータベースではそれ自身にリクエストやレスポンスをキャッシングするようなメカニズムを備えているものもあります。
 LDAPやリレーショナルデータベースに対する認証でのキャッシング
Ploneはユーザデータの特別な保存場所に対してユーザ認証をすることができます。一般的なのはLDAPやリレーショナルデータベースでしょう。これらの異なる種類のサーバに対して異なるアドオンプロダクトが存在しています。こういったアドオンプロダクトには認証をキャッシングする機能が備わっているものがあります。つまり、ページや画像を保存するわけではなく、たとえば「joelburton」はこのシステムのユーザであり、そのパスワードは「jUnEROx!」であり、システムのマネージャである、というようなことを保存するのです。そうすることで、リクエストがあるごとにLDAPサーバを煩わせることなく、このシステムのスタッフであるということを信用するわけです。
 ZODBでのキャッシング
 （ふつうPloneのコンテンツすべてを保持する）ZODBはそれ自身にオブジェクトをキャッシュする機能があります。言い換えれば、誰かが「news-items/project-a」というコンテンツを見たとすると、 ZODBは何分かの間それを保持し、さらにそのコンテンツにリクエストがあった場合には、メモリにコピーされたものを使います。ただし、これは「生の」オブジェクトであり、それが呼ばれた結果物でもなければ、スキン化されたものでもありません。この種のキャッシングは透過的であり、最新のものなので、全然悪い事ではありません。
 ZEOでのキャッシング
 ZEOは巨大なPloneサイトを複数のサーバでスケーリングする技術です。ZEOにおいては分離されたオブジェクトが一つのサーバに保存され、あるものは他のサーバに保存されます。ZEOは個々のサーバに、オブジェクトをキャッシュする準備ができたことを知らせます。そして同じサーバがそのオブジェクトを必要としたときにそのプライベートコピーを利用するのです。このキャッシングはZODBのキャッシングに非常によく似ており、同様に透過的で有効です。

 これら4つのタイプのキャッシングはCacheFu に利用されません。ZODBやZEOのキャッシングは完全に透過的に機能し、何の影響も受けません。他の二つはアプリケーション特化で、プログラマー、サイトを構築する人の影響を受けます。CacheFuはこれらの機能には関与せず、CacheFuのキャッシングはこれらのキャッシングの上で働きます。

最初の読者たち

CacheFu、そしてキャッシング一般は、これを理解しようとする、あるいは理解しなければならない人にとってとても複雑です。すべての人にすべてのことを教えるよりも、このセクションでは異なる読者にそれぞれの概念を教える事にします。Ploneでサイトを構築する人は、複雑なプロダクトを開発する人ほど詳しく知る必要はないでしょうし、一般的なサイトを運営する人は、何千ものユーザをかかえる巨大なサイトを運営する人ほど詳しく知る必要もないと思います。

エンドユーザ

サイトを利用はするがコンテンツを作ったりスキンをデザインしたりはしないようなエンドユーザはCacheFuについて何も知る必要はないし、ブラウザの設定を変更したりする必要もないでしょう。CacheFuはすでにリクエストされたとおりの動作をしています。

ふつうにインストールした場合、anonymousユーザが最新でないコンテンツを見るケースが一つだけあります。ユーザがページを見ているとき、 Ploneはふつう左側にナビゲーションを表示します。ここでSquidを使っていたとすると、anonymousユーザに対してはキャッシュされたコピーが表示されますが、このページのナビゲーションは最近生成された別のオブジェクト（たとえばニュースA）などを表示しない可能性があります。これはユーザがanonymousで、かつSquidが利用されていた場合に起こりえます（なぜならこのような状況ではCacheFuはもっとも積極的にコンテンツをキャッシュしようとするからです）。

この状況は（たとえ何も変化が無くても）1時間後にタイムアウトします。CacheFuは1時間たつと、Squidに「もうこのページはユーザに返さなくていいよ」と教えるので、その後はニュースAなどといった最新のコンテンツが表示されるようになったページを返すようになります。

もしあなたがこの動作を気にくわないなら、1時間よりも時間を少なくすることができます。もしあなたが完全に最新のナビゲーションを表示したいならば、この場合はSquidを停止させることになるでしょう。

ログインしたユーザには（ふつうにインストールしたときは）最新のコンテンツがナビゲーションに表示されないということはありません。CacheFuのデフォルトの設定では、ログインしたユーザに対しては、コンテンツページがSquidに保存される事はないからです。

コンテンツマネージャ

コンテンツマネージャはエンドユーザと同じように、特にCacheFuについて知る必要はありません。またエンドユーザのように、最新のコンテンツがナビゲーションに表示されないと言うような事もありません。

コンテンツを作った人が最新のコンテンツにリンクを貼ると、すべての人がそれを見る事ができるようになるでしょう（もちろんそのコンテンツに対する権限を持っていればの話ですが）。しかし、（anonymousユーザがそのページを見たときに）そのページのナビゲーションに最新のコンテンツが表示されるかどうかはわかりません。

ZMIからカスタマイズする人

これは具体的には以下の事をするような人を指します：

  • テンプレートやCSSをカスタマイズする人
  • Pythonスクリプトを書いたり、外部メソッドを使ったりする人
  • Ploneの設定を変更（ナビゲーションで表示するアイテムを変えるなど）する人

あなたがCacheFuの多くの恩恵を受けるためには何の変更を加える必要もないということを理解しておくとよいでしょう。しかし新しいポートレットやスキンを書いたりするときには、最新のコンテンツを表示させるために設定を調整する必要も出てくるかもしれません。

まずはCacheFuの一般設定を見てみましょう。

Cache Configuration Tool

CacheFuのほとんどの設定はCache Configuration Toolで設定されます。これは「サイト設定」→「Cache Configuration Tool」から見つける事ができます。

このツールには4つのタブがあります：

Cache Configuration Tool
これはCacheFuのワイドな振る舞いを設定します
 Caching rules
 このタブでは異なる状況でどのようなキャッシングをするかを決めます
 Cached header sets
 このタブはキャッシングルールがどのように実行されるかを決めます
 Cached macros
 このタブは実験的に実装されているマクロキャッシングのためにありますが、デフォルトではこの機能はオフになっています
 Page cache
 これはメモリ上にキャッシュされたコンテンツをクリアするためのものです

Cache Configuration Tool Tab

CacheFuはCacheFuだけで利用することができます（Zope only）。これはZopeのフロントに（SquidやApacheなどの）プロクシサーバが何もないことを意味します。この場合にはZopeとウェブブラウザ上でキャッシュされることになります。

しかし、もしApacheやSquid以外のプロクシサーバをZopeのフロントに置いたときには、CacheFuはプロクシサーバに対してJavaScriptやCSSなどをキャッシュするようにヘッダを渡します。

一方Squidを置いた場合には、CacheFuはApacheなどを置いたときと同様のヘッダを渡し、それにプラスして（Squidは消去要求をサポートしているので）選択的にSquidからキャッシュをクリアすることで、もっと他のページをキャッシュさせることも可能です。

もしかしたらApache（Squidにはできないことができる、多くのアドオンプロダクトを持った多機能ウェブサーバ）を利用する必要があり、かつ、Squidも利用したいということがあるかもしれません。このときには「Zope behind Squid behind Apache」を選んでください。Apacheを通してリクエストされたPloneサイト上のコンテンツはSquid自身によって返されるかもしれませんし、あるいは実際にZope/Ploneが答えるかもしれません。

もしあなたがSquidと一緒に利用しようとしているならば、後述する「Setup with Squid」を読んでください。どのようにSquidを設定するかということについての重要な情報があります。

もしあなたがApacheと一緒に利用しようとしているならば、httpd.confのバーチャルホストの設定が必要になるでしょう。後述部を参照してください。

もしあなたがZope単体で利用しようとしているならば、特に設定は必要ありません。

Site Domains

CacheFuがSquidにキャッシュさせたページを消去するように伝えるためには、CacheFuはSquidが稼働しているドメインを知る必要があります。

例えばあなたが「www.example.com」というサーバを動かしているとすると、例えばキャッシュされたabout-usのページは「www.example.com/about-us」に存在する事になります。Squid（あるいはSquid+Apache）の設定によって、（wwwの無い）「example.com/about-us」でも同じページを見る事ができるかもしれません。

CacheFuはこれらのURLの両方を消去するようにSquidに伝えなければならないのです。CacheFuはこれらのページが同じものであると知っていても、Squidはこの2つのページが同じだと言う事をしらないからです。

そのためにあなたはすべてのドメイン名をここでリストアップしなければなりません。そして最後にポート番号（通常80番）を付けるのを忘れないでください。もしhttpsも利用しているならば、「https://example.com:443」「https://www.example.com:443」も含める事を忘れないでください。

さらに注意して欲しいのは、ここで記述するポート番号は一般的に訪問されるポート番号であって、実際にZopeのインスタンスが使用しているポート番号ではないということです。たいていのZopeは8080番ポート（MacOSでは8282番）を利用しますが、Squidに関して言えばオリジナルのリクエストが大切なのであって、これは80番ポートから得られるからです。

あなたがSquidを利用していないのならばここは空欄にして置いてください。ここに入力した値が意味を持ってくるのは「Zope behind Squid」や「Zope behind Squid behind Apache」を選んだときだけです。

Squid URLs

もしあなたがSquidとZopeだけを使っているならば、Squidはふつうインターネットからのリクエストに80番ポートで応えます。CacheFuは消去リクエストを80番ポートのSquidに送る方法はもともと知っているので、この場合は空欄のままでOKです。

しかしSquidが80番ポートで動いているとは限りません。もっともよくあるのは、SquidのフロントでApacheが起動しておりApacheがインターネットからのリクエストを最初に受け取るような場合です。この場合は、CacheFuにSquidがどこにいるのか教えてあげる必要があります。ふつうこれは「http://127.0.0.1:3128」になります。

もしあなたがSquidを別のPCで起動していたり、異なるポートで動いてたりしているならば、この欄にどこで動いているかを入力してください。また複数のSquidを立ち上げているならば、消去リクエストを送る事ができるように「すべての」Squidをここにリストアップしてください。

Compression

キャッシングの話とは別に、CacheFuはページを圧縮する事も可能です。

この圧縮技術はウェブテクノロジーの一般的な部類のものです。ページは「gzip圧縮」で圧縮されて送られ、たいていのブラウザはこの圧縮されたページを受け取るとこれを解凍し、ユーザに表示します。

「Never」はもっとも安全な選択肢です。ブラウザによる対応の違いを考えずにすみます。

「Always」は尋常でない選択肢で、これを選ぶのはおそらく間違いです。いくつかのブラウザは圧縮されたページを扱う事ができません。すなわち圧縮ページを常に送ると言う事は、そういったブラウザを使う人たちにあなたのサイトを見せないと言うことになるのです。

ケースバイケースでブラウザが「Accept-Encoding」ヘッダに何を送るかによって決める事もできます。このヘッダはブラウザによって送られるもので、どんな種類のコンテンツを受け取る事ができるかどうかを示すものです。ブラウザが圧縮コンテンツを受ける事ができると示したときに、圧縮ページを送ります。

「Accept-Encoding」と「User-Agent」ヘッダの両方を利用する事もできます。「User-Agent」はそのブラウザがどんなブラウザなのかを示すものです。もしこのオプションが選択されると、CacheFuはこのブラウザが圧縮コンテンツを扱えるかどうか、および上手く扱えるブラウザかどうかをチェックします。ただしUser-Agentをチェックするのはとてもコストがかかる可能性があります。SquidはそれぞれのブラウザとOSの組み合わせに関して異なるバージョンのキャッシュを確保するでしょう。結果としてあまりヒットしないようなバージョンのキャッシュのためにディスク容量を消費することになってしまいます。ほとんど不具合のない「Accept-Encoding」を使うのがよいでしょう。

Vary Header

最新ではないコンテンツを送らないために、キャッシュシステム（プロクシサーバやブラウザでのキャッシング）は、そのコンテンツのURL以外のことも知る必要があります。たとえば「http://example.com/about-us」というページのキャッシュを返すときに、このページが英語で書かれているにもかかわらずギリシャ語を話す人にこれを送ってしまうような場合はまずい事になります。

よってこの欄には、プロクシサーバやブラウザによって理解される、結果を変えるための値を列挙します。

たとえば「Accept-Language」というヘッダがセットされているときに「http://example.com/about-us」がリクエストされたとすると、キャッシュプログラムはそのページを「Accept-Language」の値と共にキャッシュされることになります。このとき、再び「Accept-Language」をもったリクエストが来たとすると、「Accept-Language」の値が同じだった場合にのみキャッシュされたページが返されます。値が同じでなければ新しく生成されたページが返され、このページは「http://example.com/about-us」のもう一つのコピーとしてキャッシュされます。

もしあなたのサイトが複数言語に対応しているならば、ここに「Accept-Language」と入力しておきましょう。こうすることで、ギリシャ語を話す人に英語のページを表示する事を避ける事ができます。

特に複数言語には対応していない、あるいは他の言語ではページを返したくない（PlacelessTranslationServiceをプロダクトからはずせばOK）場合には、「Accept-Language」を削除します。この値を保持すると言う事は、キャッシュシステムがAccept-Language=enの場合のページとAccept-Language=grの場合のページを別々にキープするということを意味します。たとえそのページの表示が言語によって変わらなくとも、です。キャッシュのためのメモリも増えますし、Zopeにリクエストが届く頻度も多くなります。

もしあなたが上記の圧縮を許しているならば、Accept-Encodingもここに書こうと思うかもしれません。ここにAccept-Encodingを書くと言う事は、あなたが圧縮したページと圧縮していないページを同じものと考えていないということになります。言い換えれば、それぞれ別のページとしてキャッシュされるということになります。

あなたのサイトが複数言語サイトであり、かつ、圧縮を許可しているならば両方を書いておきましょう。

Caching Rules

キャッシングルールはCacheFuの中核となる概念です。これはZopeへのリクエストを分析してルールを適用するためのルールセットです。ルールがリクエストにマッチするとそのルールに応じた動作が適用されます。

たとえばブラウザがあるCSSを受け取り、このリクエストがZopeまで届いたとすると（すなわちSquidなどが返したわけではないとすると）、リクエストはここで設定したルールのチェックを受けながら届きます（ルールは上から下へ順番に評価されます）。マッチしたルールは次のような感じで適用されます：

  • そのページをZODBのメモリにキャッシュする
  • ヘッダを含んだリクエストがレスポンスと共に送られ、これらのヘッダはブラウザによって解釈され、プロクシにキャッシュされる（たとえば「これを１時間キャッシュしておくように」とか「これはキャッシュしないように」などというように）

ルールは一番最初にマッチしたものが採用されるので、すべてのリクエストに対して一つのルールだけが適用されます。もし一つもルールがマッチしなかった場合は、何も起こりませんし、そのページはふつうに返される事でしょう。

それではCacheFuに最初から備わっているルールを少し見てみましょう。これらのルールを理解する事が、CacheFuを理解する事につながります。

HTTPCache

このキャッシュはCacheFuの外側でマッチする事はありません。しかしこれをカスタマイズすると非常に便利です。

このルールは、（変更される事がなく）完全にキャッシュされてもよいページ（あるいはたとえばロゴなどの画像）があるときに使われます。ログインしてもしなくても、コンテンツの内容が変更されても、「常に」同じように見えるページを想像してみてください。あなたのサイトに関する（静的な）ヘルプなどが良い例です。コンテンツを持たない、あるいはコンテンツに依存しない、あるいはログインの状態によって変更のないようなものが該当します。ここでsite-helpというページテンプレートを考えてみましょう。

このページをキャッシュすることをCacheFuに教えるためには、あなたはこれをHTTPCacheというキャッシュマネージャに関連づける必要があります。そのためにsite-helpテンプレートにいって、CacheタブからHTTPCacheに関連づけることになります。

これまでZopeでこのことをするためには、Acclerated HTTPCache ManagerというHTTPCacheに関連づけていたかと思います。そしてこのキャッシュマネージャはヘッダにそれ自身をセットしていました。しかしCacheFuではHTTPCacheそれ自身は特にアクションを起こしません。ただ当該オブジェクトに関して、HTTPCacheされうることをマークづけするだけであり、だからこそ、そのページはこのルールに適合する事になるのです。

ここで実際のCacheFuの設定を見てみると、デフォルトではどのコンテントタイプも選択されていないので、すべてのタイプのコンテンツにこのルールが適用される事になっています。

いくつかのオプションもありますが、ここでは特に使われていません。

anonymousに対するヘッダと認証ユーザに対するヘッダは、ルールに対する最初の成果となります。このルールに適合したコンテンツは、デフォルトでanonymous、認証ユーザ両方に対して24時間ブラウザにキャッシュします。もし1時間だけこれをキャッシュしたいならば、ドロップダウンメニューから「cache-in-browser-for-1-hour」を選びます。もしここにない選択肢（例えば10分だけキャッシュさせるなど）を使いたいならば、ヘッダセットタブでその選択肢を作る事もできます。

最後にある「Last-Modified Expression」は、そのコンテンツがいつ更新されたのかを決定するために使われる表現です。

Content

このルールは、（フォルダでもイメージでもない、例えばニュースアイテムのような）ふつうのコンテンツのキャッシュに使われます。

デフォルトではPloneのふつうのコンテンツがこのルールによってキャッシュされます。これを他のキャッシュマネージャに関連づけることは特に必要ありません。

このルールにマッチさせるコンテンツは「Content Types」で選ばれています。ここで選ばれているのはファイルやイメージ、フォルダではないコンテンツタイプです。

もちろんニュースアイテム「そのもの」をキャッシュしたいわけではないでしょう。むしろここでは、そのニュースアイテムのHTMLとしてのビュー（View）をキャッシュしたいわけです。

デフォルトビューがチェックされたとき、このルールは、リクエストがスキンオブジェクト（ページテンプレートやPythonスクリプトなど）に対して送られてきたときに適用されます。なので例えばこのルールは「http://news-items/project-a」と「http://newsitems/project-a/newsitem_view」に適合します（newsitem_viewはニュースアイテムのデフォルトビューなので）。しかし一方で「http://news-items/project-a/special_newsitem_view」には適合しません。

「special_newsitem_view」のような特別なビューをキャッシュさせたい場合は、「Templates」フィールドにそのIDを追加します。

「Cache Templates」は、このルールにマッチするテンプレートだけでなく、テンプレートの結果もキャッシュすることを意味します。これはたとえプロクシキャッシュがなくてもCacheFuがメモリキャッシュを利用するのに役立ちます。

「http://news-item/project-a」と「http://news-item/project-a?form_var=1」は異なるリクエストであり、これは別々にキャッシュされるということに注意してください。

「Cache Preventing Request Values」はこのようなフォームの変数などを特定するのに利用されます。これが存在した場合は、そのリクエストはキャッシュされません。デフォルトでは「portal_status_message」がここにリストされています。「portal_status_message」はふつうフィードバックメッセージのために使われるもので、デフォルトではオレンジ色で表示されます。一つのページテンプレートはいくつものフィードバックメッセージ（変更が保存されました、とか、コンテンツが追加されました、などなど）で表示されるので、それぞれのコピーをキャッシュしておくのは非常にディスク容量を浪費し、訳にもたちません。そのためCacheFuはこういったメッセージが存在するときにはそのページはキャッシュしません。

「Predicate」を使えばさらにTALES表現によってチェックする事が可能です。すなわちリクエストは、「Content Typesで選択されている」「デフォルトビューである、あるいは明示的に選択されたテンプレートである」「portal_status_messageを含まない」、そして「この表現をパスする」ことによって、ルールが適用されるのです。

デフォルトでは「Header Set for Anonymous Users」は（Squidなどの）プロクシキャッシュに1h保存されるように、また認証ユーザに対してはETagによってキャッシュするようにセットされています（Header Set for Authenticated Users）。ETagは変更があったときに最新情報を送るようにするためのメカニズムです。

ETagについて

ETagはウェブサーバとブラウザの間でやりとりされる付加情報を扱うメカニズムです。この付加情報はたとえば、リクエストしたユーザの種類や最終更新日などです。

なのでたとえば「http://news-items/project-a」をリクエストしたとき、サーバは「ETag: joelburton-2006/12/25-en」というようなETagを含めた応答をします。

このETagは「このリクエストはJoel Burtonに対するもので、このコンテンツは2006年のクリスマスに更新され、英語で記述されている」ということを意味しています。キャッシュプログラムはコンテンツとともにこのETagも保存するでしょう（このETagは正確なフォーマットではありませんが、概念としては正しいものです）。

ここでブラウザがこのページをもう一度リクエストしたとき、古いETagもZopeに送ります。Zopeはその時点で生成されたETagと古いETagを比較し、同じであるならば「何も変更はないよ。キャッシュを使ってね」というHTTPレスポンスを返します。もちろん違っていれば新しいページを返します。

たとえば「ログアウトした」Joelが再び「http://news-items/project-a」を訪れたとき、まず彼のブラウザはZopeに対して最後に訪れたときのETag（joelburton-2006/12/25-en）を手渡します。一方Zopeは（Joelは今ログアウトしているので）「anonymous-2006/12/25-en」というETagを生成します。これは以前とは異なっているETagであり、誰だかわからないanonymousユーザにはJoelとは違ったページが必要なので、コンテンツそのものを返す事になります。

SquidはETagを扱えないので、この種のリクエストはSquidをスルーします。

「ETag Components」では、どんなものを付加情報としてETagに含めるかと言うことを選びます。ここで選択したものに変化があった場合は、ETagに変更が加えられ、その結果ページは最新のものが利用されます。

デフォルトの設定はまともですが、少し注意が必要です。もしそのページや現在のスキン、圧縮されているかどうか、あるいはカタログが最後に変更された時間をリクエストしたユーザに変化があった場合は、再生成されることになります。

ここでリストされているものは興味深い例になります。もしあなたが新しいアイテムを編集したときには、もちろんCacheFuには古いアイテムを返して欲しくはありません。そしてたとえばそのニュースを含んでいるフォルダのタイトルを変えた場合も、古い見え方を返しては欲しくないですよね。なぜならそのフォルダのタイトルは、ナビゲーションやパンくずリストなんかに現れるからです。それが古いままでは困ってしまいます。

ETagに、カタログの最終更新日を含めると、どんなオブジェクトのどんな変化であってもCacheFuのページ再生成を引き起こしてしまいます。このことは最新のナビゲーションを保証してくれますが、ちょっとばかり古くても良いような部分でこのようなことが起こるのはちょっともったいないです。

が、このETagはログインしたユーザのためのものです。anonymousユーザに対しては（ETagにかかわらず）プロクシサーバに1時間保存されます。ですからすべての変更がキャッシュに無効になるわけではありません。

もしあなたが最新状態にこだわらず、もうちょっとパフォーマンスをよくしたいとおもうならば、「Time of last catalog change」を「Context modification time」に変えてみるのも良いでしょう。これは、すべての変更がすべてのETagを無効にするわけでもないが、古いタイトルなどが表示されてしまうかもしれないということも意味しています。これはパフォーマンスをよくしますし、一度検討してみることをおすすめします。

ETagを選択肢から選ぶのもよいですが、リクエスト変数をETagに明示することもできます。デフォルトでは「month」「year」「orig_query」変数がリストアップされています。これはカレンダーポートレットのための設定です。コンテンツに何も変更を加えなかったとしても、カレンダーポートレットで「next-month」ボタンを押したユーザには、コンテンツは同じでもポートレットだけは次の月のものを表示するのです。

もしここに他のフォーム変数を追加すれば、そのページのキャッシュのされたかは違ってくるでしょう。

ただ前述した「Cache Preveting Request Values」（「portal_status_message」のところで述べました）との違いに注意してください。cache-preventing-valuesは「もしこの変数があったら、ルールを適用しないでね！」という（のでキャッシングヘッダは送られない）のに対して、「ETag request values」は「もしこの変数があったら、キャッシュできるけど別のリクエストとみなしちゃうよ！」というわけです。

「ETag Timeout」は安全のための設定です。これはETagが持続する時間で、デフォルトでは3600秒です。これはもしETagの比較によって何の変化がないと判断されたページであっても、ETagの生成から3600秒経過していたら、とにかく新しいページを生成するということです。

「ETag Exprssion」は追加的なETagの値を記述するためのものです。

「Purge Expression」はSquidのコンテンツを消去するためのスクリプトを記述するためのものです。とりあえず編集しなくてもOKです。

Container

このルールはフォルダ風コンテンツタイプ（フォルダとPloneラージフォルダ）に使うもので、Contentルールに似ています。
違いは、Contentルールがanonymousユーザに対してはオブジェクトが変更されるまでキャッシュするのに対し、このルールはより長い時間キャッシュするということです。フォルダは多くの場合それが含むオブジェクトのリストを返すだけなので、このフォルダの見栄えを最新のものにする必要があるのは、新しいドキュメントが追加されたときやそのフォルダに含まれるドキュメントが変更されたときです。
しかしフォルダに含まれるオブジェクトが変更したかどうかはとても知るのが難しいことです。そこでCacheFuはもう少し手軽で一般的なものをチェックします。全体のカタログの中で変更されたものはないか？ということです。カタログの中で変更されたものがあればフォルダ風オブジェクトは再生成されることになります。
このためフォルダ風オブジェクトはSquidやApacheにキャッシュされることは決してなく、ZopeでContentのETagと同じようにキャッシュされます。つまりanonymousユーザに対しても、ログインユーザに対しても、Contentルールのログインユーザに対するように振る舞うことになります。

Templates

このルールは、コンテンツやフォームを含まないページテンプレートのようなスキンオブジェクトに使われます。この良い例はアクセシビリティ情報です。これはコンテンツでもフォームでもありません。しかし変更があるまではキャッシュすることができます。
「templates」フィールドにはこのルールにマッチさせるテンプレートを記述します。新しいテンプレートを追加したときもここに追加することができます。
これらは上記のコンテンツやフォルダ風オブジェクトと同じようにETagによってキャッシュされます。
フォルダ風オブジェクトのルールと同じように、このキャッシュはカタログに変更があった場合にクリアされます。ほとんどのテンプレートはmain_templateに依存しており、またこのmain_tamplateも他のテンプレートに依存しているので、これらの依存状況を追跡するのは非常に難しいことです。よってZopeの中でのどんな変化も、このテンプレートが何を表示するか、クリアするかといったことに影響を与えるようになっています。
これは非常に安全です。もしかしたら、anonymousユーザのためにこれらのテンプレートをプロクシサーバに1時間以上（あるいは24時間以上、あるいはもっと長い時間）キャッシュさせたい人がいるかもしれません。テンプレートそのものの変更、あるいはmain_templateなど、その他テンプレートの変更は表に現れませんが、この種の変更はほとんどレアですし、もし変更があったとしてもサイト管理者はプロクシキャッシュをクリアするためにプロクシサーバを再起動することもできます。

なぜフォームは除くのか？

それじゃあフォームはなぜTemplateルールでキャッシュされないのでしょう？
Ploneでのフォームは、フォームを見せるだけでなく、エラーメッセージを表示するためにも使われます。これをキャッシュしてしまうと、フォームを入力しようとするユーザに対してエラーメッセージを表示してしまったり、すでに入力されたものを表示してしまったりしまいます。
Document Actions