Magento Cache-Varnish、Redis、APC、Memcacheに関する混乱

私はMagentoのパフォーマンスを改善しようとしています（遅かれ早かれ「MageDev」がこの点にぶつかりました：）

私はいくつかの研究を行い、多くの良いガイドを見つけましたが、同質ではありません。

私が得たのは：

• MemCacheまたはRedisは汎用キャッシュシステムであり、データをキャッシュし、Magento（local.xml）と直接統合できます。
• APCは、PHPコード自体のキャッシュであり、サーバーレベルでのみ統合できます。
• Varnishはリバースプロキシであり、サーバーレベルでのみ統合できる応答をキャッシュします。（Magento、テレビン油の拡張子がありますが、何が正確に行われるのかわかりません）

すべてのこの良い読書の後、私はまだ上記のキャッシュシステムのどれがEXで組み合わせて使用​​できるかについて少し混乱しています：

• MemCache + APC？
• Redis + APC？
• 上記の構成のいずれかにワニスを追加できますか？

質問を明確にするために、Magentoやサーバーの設定方法についてではなく、キャッシュシステムを混在させる方法について許可される可能性とクリアランスについて説明します。（それ以外に、もし誰かが良い提案をすることができたら、感謝します。）

TL; DR -MageStackでは、Varnish、Redis（キャッシュ）、Redis（セッション）、およびEaccelerator / Zend OPCache（PHPバージョンに依存）を使用します

すでにそのほとんどが理解されています。

キャッシュバックエンド、セッションストア、オペコードキャッシュ、フルページキャッシュ、リバースプロキシキャッシュはすべて完全に異なります。

すべてに異なるテクノロジーを使用でき、それらをすべて同時に使用できます（ワニスとFPCを含む）

キャッシュバックエンド

• ファイル（コア）デフォルト
• Memcache（コア）
• APC（コア）
• Redis（<1.9モジュール提供：Colin Mollenhour）
• MongoDB（モジュール提供：Colin Mollenhour）
• Rubic（モジュール提供：Daniel Sloof）

使用できるキャッシュバックエンドは1つだけです。

一般的な考えに反して、メモリベースのキャッシュを使用してもパフォーマンスは向上しません。しかし、Magentoのデフォルトのファイルベースのキャッシングの致命的な欠陥を克服します。

このメッセージを書いている時点で、Redisが私の推奨です。

セッションストア

• ファイル（コア）デフォルト
• Memcache（コア）
• Redis（<1.9モジュール提供：Colin Mollenhour）
• MongoDB（モジュール提供：Colin Mollenhour）

使用できるセッションストアは1つだけです。

一般的な考えに反して、メモリベースのセッションストアを使用してもパフォーマンスは向上しません。

このメッセージを書いている時点で、Redisが私の推奨です。

OpCodeキャッシュ

• APC
• XCache
• Eaccelerator（PHP <5.4）
• Zend OPCache（PHP> 5.4）

実際には複数のオペコードキャッシュをインストールできますが、これはお勧めできません。

私の推奨事項は上記の括弧内にあります。

これを活用するためにモジュールをインストールする必要はありません。

リバースプロキシキャッシュ

• ワニス
• Nginx
• アパッチ
• … などなど

複数のリバースプロキシを使用できます。これは複雑であり、キャッシュの延長が発生しやすい一方で、メリットがあります（キャッシュフラッシュ中のスタンプを防ぐため）。

必要に応じて使用してください（つまり、低速サイトの速度を上げるためではなく、高速サイトのリソース使用量を減らすため）。

リバースプロキシを活用するには、サーバー側の有効化とMagento用のモジュールの両方が必要です。

このモジュールの理由は、キャッシュロジックの制御（キャッシュにキャッシュすべきものとすべきでないものをキャッシュに伝えるため）と、キャッシュコンテンツの管理（つまり、キャッシュのパージをトリガーするため）です。

あなたが何をしているかを完全に理解していない限り、私は何もお勧めしません。逆プロキシを不適切に設定すると、ヘッダー情報が破損したり、セッションが失われたり、セッションが共有されたり、コンテンツが古くなったり、時間/バッファの読み込みに追加の制限が適用されたり、追加のリソースが消費されたりする可能性があります

全ページキャッシュ

• EE FPC
• …他の多く（モジュール経由）

必要に応じて使用してください（つまり、低速サイトの速度を上げるためではなく、高速サイトのリソース使用量を減らすため）。

一般的な信念に反して、リバースプロキシキャッシュと組み合わせてFPCを使用できます（また使用する必要があります）。2つは異なる問題を解決し、異なる機能を備えています。

FPCはユーザーセッションとMagentoのコアに直接アクセスできるため、より多くのインテリジェンスを活用できますが、リバースプロキシはアプリケーションを認識しません（動作がかなりおかしいです）。 。

すなわち。ワニスやFPCとは思わないで、ワニスとFPCを考えてください。

ワニスを上にしたRedis + APCに行きます。

「なぜRedis」と尋ねますか？この優れたSOの回答をお読みください。Redisは、基本的にMagentoの標準のファイルベースのキャッシュシステムを置き換えます。Redisは高速なので、速度がいくらか向上します。

実際、ワニスは内部の仕組みとはあまり関係がありません。最上位に配置され、静的コンテンツをキャッシュするため、リクエストとして実際にMagentoに到達することはありません。穴あけされた部品を除きます。

Varnishはフロントエンドキャッシングのみに焦点を当てていますが、RedisはEAVや設定キャッシュなどの他のタイプのキャッシュも高速化します。

必要に応じて、ワニスの代わりにMagentoのフルページキャッシュ拡張機能をチェックアウトできます。それほど高速ではありませんが、一般的に実装が簡単で、追加のソフトウェア（Varnishなど）に依存しません