以前の記事で何が起こったのかについて簡単に説明します....
最初は、使用したプロジェクトはビューキャッシュを使用していました。 しかし、このアプローチは私と同僚に多くの不便をもたらしました。
- データ検証の複雑さ：データベースへの書き込み時には、さまざまな関連ブロックからデータをダンプする必要がありました。この混乱エラーが頻繁に発生したためです。
- キャッシュ内の余分なデータ：データベースからのデータではなく、html-resultがキャッシュされます。 データが多く、負荷が大きいほど、ロードに時間がかかります。 もちろんささいなことです。 しかし、それでも！
そこで、モデルをキャッシュすることにしました。 これには何が必要ですか？ このテーマでPropelによって生成されたクラスを研究した後、PEERクラスにあるプールを使用することが決定されました。 ORM開発者が考えたように、このプールは作成されたオブジェクトをすでにデータベースに保存しています（isNew == false）。 PropelはdoSelect / One / ...メソッドを通してオブジェクトを受け取ったときにプールにオブジェクトを追加します。 同時に、retriveByPkメソッドが呼び出された場合にのみ、同じプール内のオブジェクトの存在を確認します。 これに基づいて、retriveByメソッドを使用する場合、一意のキーによるオブジェクトの関連付けもキャッシュを使用できます...（以前の記事でさらに詳しく）....
これらすべての結論の過程で、これをすべて実装するsfPropelMemcachePluginプラグインが作成されました。私の意見では非常に成功しています。
- キャッシュサイズが400 MB（これはキャッシュ設定の最大値）から100MBに減少しました。
- 検証に混乱はありません。 モデルが変更され、キャッシュが変更されました。 ほとんどの部分のテンプレートはキャッシュされず、タイプセットが簡単です。
- データベースへの単純なクエリは、主キー（または一意のキー）の大部分で使用されます。
プラグインは現在、主キー、一意キー、複合キーを使用したキャッシュをサポートしています。
プラグインはまだベータ版なので、厳密に判断しないでください。
本番環境でのプラグインの作業スケジュール。
ユーザーのキャッシュモデル、彼のプロファイル、国、地域、都市、写真（+アバター）、写真のフォルダー。
プラグイン自体。
PS建設的な批判や提案に喜んで耳を傾けます。