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

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

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

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

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

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

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

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

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

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

本質的には3つの場所でキャッシュされることになります。

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の一般設定を見てみましょう。

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

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

Cache Configuration Tool

これはCacheFuのワイドな振る舞いを設定します

Caching rules

このタブでは異なる状況でどのようなキャッシングをするかを決めます

Cached header sets

このタブはキャッシングルールがどのように実行されるかを決めます

Cached macros

このタブは実験的に実装されているマクロキャッシングのためにありますが、デフォルトではこの機能はオフになっています

Page cache

 これはメモリ上にキャッシュされたコンテンツをクリアするためのものです

Cache configuration

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を 書くと言う事は、あなたが圧縮したページと圧縮していないページを同じものと考えていないということになります。言い換えれば、それぞれ別のページとして キャッシュされるということになります。

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

キャッシングルールは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の中でのどんな変化も、このテンプレートが何を表示するか、クリアするかといったことに影響を与えるようになってい ます。

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

それじゃあフォームはなぜTemplateルールでキャッシュされないのでしょう？