この 2 つのフロントエンド Zend_Cache_Frontend_Capture と Zend_Cache_Frontend_Page の違いを誰か説明できますか?
Capture はページ キャッシングのデフォルトのものです...奇妙なことに、get 変数で id を作成しますが、ページ フロントエンドの場合のように make_id_with_get_variables を設定するオプションはありません....
誰かがこれを説明できますか？
1 に答える
3
これが2つの違いを説明するための私の努力です。
まず、Zend_Cache_Frontend_Captureを見てみましょう。参照には、このクラスは。でのみ機能するように設計されていると記載されていZend_Cache_Backend_Staticます。
Zend_Cache_Frontend_Captureサイトにアクセスするユーザーとは関係のないページ全体をキャッシュするために使用します。このフロントエンドは、現在のユーザーとは関係のない静的データ（随時変更される可能性があります）がある場合、つまり、すべてのユーザー（RSSフィードや動的に作成されたJavaScriptファイルなど）で同じである場合に使用します。
Zend_Cache_Backend_Staticをさらに調べると、このバックエンドが少し特殊であることがわかります。.htaccessキャッシュの提供を支援するために、ファイルにルールが必要です。で何かをキャッシュするとFrontend_Capture/Backend_Static、キャッシュされたデータを提供するためにPHPとZendFrameworkは使用されません。Apacheは、キャッシュファイルが.htaccessに基づいて存在することを確認し、PHPを呼び出さずにコンテンツをユーザーに直接提供します。
Zend_Cache_Frontend_Page一方、動作は異なります。これを使用すると、リクエストURIだけでなく、Cookie、セッション、GET、またはPOSTパラメーターの情報に基づいてコンテンツをキャッシュできます。デフォルトでは、cookie、session、get、postに基づくキャッシュは無効になっているため、サイトにログインしているユーザーに影響を与えるには、それに基づいてキャッシュするページがあるかどうかをキャッシュに通知する必要があります。情報。
キャッシュを作成し、Cookieとセッションに基づいてキャッシュするように指示すると、1人のユーザーに固有の動的に生成されたページをキャッシュできるようになります。したがって、人物Aがアクセス/accounts/した場合、データベースから取得されたアカウントのリストを含む特定のユーザーのページをキャッシュできます。これで、人物Bがにアクセスしたときに/accounts/、人物Aのキャッシュが表示されないため、ページは、それぞれのユーザーの情報をそれぞれのキャッシュに入れて、個別にキャッシュされるようになりました。
要約すると：
すべてのユーザーで同じキャッシュできるデータがある場合は、キャプチャフロントエンドを使用します。ページがキャッシュされるとPHPとZFが不要になるため、これはより高性能なキャッシュになります。欠点は、.htaccessにキャッシュルールを追加する必要があることです
リクエストURIだけでなく、Cookie、セッションデータ、またはget / postパラメータに基づいて動的に出力されるページをキャッシュする場合は、ページフロントエンドを使用します。
それが明確で、違いを理解するのに役立つことを願っています。
編集： 私は問題が何であるかを理解していると信じていますが、これがバグとして分類されているかどうかはわかりません。
Zend_Controller_Action_Helper_Cache::preDispatch()リクエストURI（クエリ文字列を含む）に基づいてキャッシュIDを生成します。jQueryティッカーはクエリ文字列をURLに追加するため、リクエストURIごとにフィードのコピーを1つキャッシュします。（前述のクラスメソッドで$ reqUriを探します）。
いくつかのオプションがあります：1）クエリ文字列を追加しないようにティッカーを取得できるかどうかを確認します（少なくともその特定のURLに対して）または2）キャッシュヘルパーに許可するのではなく、キャプチャキャッシュを手動で開始して独自のIDを渡しますリクエストURIに基づいて生成しました。
于 2012-02-10T22:25:16.257 に答える