CE 1.8のフルページキャッシュ-FPC Magentoモジュール？ワニス？どちらも？

したがって、Community Edition 1.8のフルページキャッシュの調査に取り掛かるとき、少し混乱しています。私はすでに2レベルのRedisキャッシュ、CDNを実装し、MySQLのmy.cnfを最大限のパフォーマンスに調整しました（もちろん、DBは別のサーバー上にあります）。最初のパフォーマンス調整を行う前に、すぐにFPCにジャンプするわけではないことを指摘します。

Magentoはもちろん、あらゆるサイトでVarnishを使用したことはありません。MagentoでFPCをセットアップしたこともありません。Varnishは、CDNとそれ自体のページキャッシュとの間のクロスとして機能し、リクエストがWebサーバーに届く前にブラウザにデータを送信するプロキシであると理解しています。私の理解では、FPCモジュールはローカルにキャッシュを作成し、ウェブサーバー自体がそれを処理します。どちらのセットアップでも、ブラウザーに動的コンテンツを取得するために「ホールパンチング」を行う必要があることを知っています（ただし、モジュールを使用するか、ワニスを使用するかによってテクニックは異なります）。ここで何か誤解している場合は修正してください。

今までは、それらを実装できる2つの独立したエンティティであると考えていましたが、今読んだものはその逆を暗示しているようです。私の当初の計画は、Magento（以前は「Tiny Brick Lightspeed FPC」だったと思います）用の「Warp Advanced Full Page Cache」モジュールを購入することでした。 、私たちの会社、特に何ができるかについては、350ドルはそれほど多くありません）。私自身と仲間の開発者2人は、独自のカスタムテーマ内で適切かつ完全に実装して、最大限の成果を引き出すことを学ぶことを計画していました。それが行われた後、ある時点で、ワニスの実装も検討するつもりでしたが、先ほど言ったように、それらは別のものであると理解していました。

しかし、今では、Varnishを搭載した無料のPageCacheや、Varnish Cacheを搭載した800ドル近くのVortex Cacheのような拡張機能に出会うようになっています。

あなたへの私の質問、スタック交換、私はどのようにFPCとワニスを見るべきですか？別のエンティティとして？もしそうなら、それらは相互に排他的ですか？彼らは私が一緒に実装する必要がある同じコインの両面ですか？またはそれらは類似しているが、互いに排他的でも包括的でもないか？

上記のWarp Advanced FPCをVarnishで使用できますか？ Varnishで使用する必要がありますか？または、ワニスの使用を計画している場合、別のFPCを使用する方が良いでしょうか？または、さらに、ワニスを必要としないほど優れたFPCがありますか？またはその逆に、単にワニスを使用してFPCのアイデアを捨てるべきですか？

テキストの壁で申し訳ありませんが、私は多くの記事、ブログ、フォーラムの投稿を見てきましたが、これらの質問に対する明確な答えを見分けることができませんでした。この件についてのご協力とご意見に心から感謝いたします=）

最後に、ワニスとウェブサーバーに関する簡単な質問。現在、私は通常のApache LAMPスタックセットアップを使用していますが、しばらくの間、NginxをMagentoで使用することに絶賛されています。私はいくつかのテスト、ストレスおよび負荷テストを行ってきましたが、適切な条件では間違いなく少し良くなるようです。そのため、近い将来のある時点で切り替えることを検討していました。とにかく、これはFPCおよび/またはワニスを使用するという私の欲求と決定に影響しますか？

ありがとうございました！！！

編集：ああ！そしてもう1つの簡単な質問-ロードバランサーの背後にサイトをホストする2つのサーバーがあるので（必要に応じて水平方向に増やすこともできます）、RedisとMemcachedを別のサーバーでホストします私のセッションのWebおよびDBのものと、Magentoの各レベル（まあ、Zendの2レベルキャッシュ）。FPCはそれらのデータをシステムに保存しますか？そこに保存するには特定の拡張機能が必要ですか、それともすべての拡張機能が必要ですか？そして、私はそうではないと思いますが、これはとにかくニスに影響しますか？再度、感謝します！！

コンピュータサイエンスには2つの困難なことがあります。

1. 物に名前を付ける
2. キャッシュの無効化。

穴あけはカテゴリ＃2に分類されます:)

全般

最善のアプローチは、スタックの低いポイントから開始し、Magentoのフロントエンドまで最適化することです。

データベースとファイルシステム

常に最初に焦点を当てる領域である必要があります。なぜなら。I / O。

MyTopは便利なLinuxベースのperlスクリプトで、Linuxの 'top'コマンドを模倣し、MySQLインスタンスの状態に関する洞察を提供します。

• https://github.com/jzawodn/mytop

ホテルトップがある、より堅牢なトップ、straceのの機能潜在的なボトルネックを見つけるために、プロセスのイン/アウトを決定するのに役立ちます。

• https://github.com/hishamhm/htop

Iotopは、I / Oの監視を検討するもう1つのツールです。

• http://guichaz.free.fr/iotop/

mysqltuner.plやmysql tunning primerのような他の便利なユーティリティスクリプトは、MySQLランタイム変数への洞察を提供し、役立つアドバイスを提供します。最良のアプローチは常に要件の評価と収集された既知のデータに基づいた調整であるため、これらはガイドであることを念頭に置いてください。盲目的にこれを行うと、良いよりも多くの損害を引き起こす可能性があります。また、少なくとも24時間のmysqlランタイム変数を使用せずにこれらを時期尚早に実行すると、悪いアドバイスになる可能性があります。

• http://mysqltuner.pl
• https://launchpad.net/mysql-tuning-primer

覚えておいてくださいPercona、MariaDBと標準MySQLは、上記のすべてで動作するはずです。MagentoはInnoDBに非常に重く、XtraDBはdbエンジンに多くのツールと拡張機能を提供するため、PerconaをMySQLフォークとして好んで使用します。

• http://www.percona.com/software
• https://mariadb.org/en/about/

ApacheまたはNginx

私自身も含めて、Apacheを他の多くの人に役立っているように使用しています。Nginxも使用して設定しました。いくつかの利点がありますが、学習曲線があります。この2つはどちらも一般的なオプションですが、Apacheよりもいくつかの利点があります。1つはメモリフットプリントが小さいことです。ただし、PHP-FPMを実行しているスリムなApacheは、同様のメモリフットプリントを持ちます。

• http://arstechnica.com/business/2011/11/a-faster-web-server-ripping-out-apache-for-nginx

適例：

この記事はパフォーマンスに関するものなので、Apacheが独自の方法から抜け出すのを助ける最も簡単な方法の1つは、.htaccessファイルを使用しないことです。Directoryスタンザにそこに置くものを入れ、AllowOverrideを "None"に設定すると、.htaccessに注意を払う必要があるかどうかを判断するために、ドキュメントパス全体をトラバースするようにApacheに要求しないことになります。これは、多くの人が見逃しているように見える、基本的でシンプルなチューニングのヒントです。

このチェックアウトを容易にするために：

• https://github.com/preinheimer/htaccessConverter

CDNを使用してどちらかを容易にすることは明らかに役立ちますが、ほとんどのエンドユーザーのブラウザーは同じ数の接続制限で両方のサーバーに接続できるため、フロントエンドの最適化に利点が追加されます。また、これにより、単純な静的イメージを提供するためだけにチェックなどをジャンプする必要がなくなります。 Lighthttpdは、CDN以外のコンテンツに対してのみ静的Webサーバーを実行する場合のオプションです。

PHP

PHP-FPMおよびAPC。それらを使用し、Magentoに不要な不要または不要なPHPモジュールを取り除きます。

Magentoコードベース

AOE_TemplateHintsは、ブロックが適切にキャッシュされているかどうかを判断するのに最適です。

• https://github.com/fbrnc/Aoe_TemplateHints
• http://www.fabrizio-branca.de/magento-advanced-template-hints-20.html

AOE_Profilerはプロファイリングに適しています。DBレイヤーのプロファイリングを有効にしてください（明らかにローカル/ 開発環境で）。これは、前述のmytopツールと組み合わせて、動作不良のSQLを見つけることを容易にします。

• https://github.com/fbrnc/Aoe_Profiler

サードパーティモジュールとカスタムコード

Magento自体から最適化するためのいくつかの非常に優れたベストプラクティスは読みやすく、サードパーティのモジュールを使用する前に確認する際に留意する必要があります。（多くの悪い振る舞いのIMOがあります）。

• http://info.magento.com/rs/magentocommerce/images/Conquer_the_5_Most_Common_Magento_Coding_Issues_to_Optimize_Your_Site_for_Performance.pdf

Magento ECGのツールMagnifferは、上記のPDFに基づいて、不正な動作コードを簡単に識別するのに役立ちます。ただし、symfony / php-parserベースですが、composerを介してインストールできます。

• https://github.com/magento-ecg/magniffer

ワニス

著者であるVarnishの支持者はFreeBSDカーネル開発者であったため、クレイジーな1秒未満の読み込み時間を提供します。ただし、テンプレートにわずかな違いがあってもすぐに使用できる場合は、ワニス/ magentoの設定に時間をかけて必要なコンテンツをホールパンチします。私が見たほとんどは、ワニスからキャッシュされていない必要なアイテムを単純にAJAX化します。

このホールパンチとキャッシングを容易にするためのMagentoモジュールがいくつかあります。

• AOE_Static：https : //github.com/AOEmedia/Aoe_Static
• Nexcess Turpentine：https : //github.com/nexcess/magento-turpentine

最終的にこれはあなたの最適化の旅の最後の最後であるべき、とするかもしれ物事が権利を取得するためにいくつかのカスタマイズが必要。

Magento CE FPC

これまでのところ、私が見つけた最高のCE FPCは次のとおりです。Lesti:: FPC

コミュニティ向けの非常に適切な（すべてのオブザーバーベースの）オープンソースで無料のFPCです。

• http://gordonlesti.com/lestifpc/
• https://github.com/GordonLesti/Lesti_Fpc（デッドリンクの場合のgithub）

一日の終わりには、独自のテストと判断を使用します。

さらにいくつかの読書：

• http://www.kingletas.com/2012/08/caching-performance-optimization.html
• https://www.sonassi.com/knowledge-base/magento-with-varnish/
• http://info.magento.com/rs/magentocommerce/images/HostandBoastBestPracticesForMagentoHosting.pdf

私が知っているこのスレッドには少し遅れていますが、まだ解決策を探している場合は、Evolved Cachingを検討することをお勧めします。Warpと同じ価格ですが、次のとおりです。

• インストールと設定は非常に迅速かつ簡単です-すべてのホールパンチと設定は管理者内から行われます
• Varnishと直接統合し、Magento内からVarnishキャッシュをクリアおよびウォームアップできます
• 1.8 CEで導入されたフロントエンドform_keyで、Varnishと独自のキャッシュの両方で動作します。
• レスポンシブサポートで非常に積極的に開発されています。報告から数日以内にバグ修正をリリースすることを目的とした定期的な新バージョン
• すべてのリリースで更新される広範なドキュメントがあります

Varnishでのセットアップは簡単です。管理設定を有効にし、ここにある.vclを使用するだけです。また、通常どおりCookieが存在しない場合にのみキャッシュを提供するワニスに制限されません-非常に高いキャッシュヒット率が得られます。

Magento 1.8の新しいフォームキーと互換性のあるFPCを作成しました。Brimのフルページキャッシュ：http : //ecommerce.brimllc.com/full-page-cache-magento.html

BOOMERは、スタックの低いところから始めて、あなたの方法で作業を進めることについて素晴らしいポイントを作ります。FPCまたはワニスは、最後に行う必要があります。私たちはパフォーマンス監査を行い、一般にMySQLとAPCの構成に関する問題を見つけます。Innodbのバッファーサイズがデフォルトに設定され、データベースがそれをはるかに超えて成長したように。

共に動作するように特別に設計されていない限り、ワニスでFPCを使用しないことをお勧めします。一般に、コードベースに合わせて調整された、まだトラフィックを維持するのに苦労している少数の強力なサーバーがない限り、ワニスはお勧めしません。動的コンテンツの更新は、Magentoバックエンドへのリクエストを制限し、負荷を軽減しようとする場合に特にVarnishで注意が必要です。1つまたは2つのWebヘッドがある場合、時間と手間をかける価値はありません。

ほとんどの場合、サーバーとコードベースが調整された後、優れたFPCを使用すると、必要なパフォーマンスが得られます。FPCを使用すると、レベル1キャッシュで15ミリ秒未満の生成時間、標準キャッシュで100ミリ秒未満の生成時間を取得できます。レベル1キャッシュは、ユーザーがログインしておらず、カートに穴を開けないため何も持っていない場合に使用されます。これらの条件のいずれかが偽の場合、標準のキャッシュが使用され、完全な穴あけサポートが使用されます。

FPCには簡単な穴あけが組み込まれており、すべての標準Magentoブロックとカスタムブロックを使用してすぐに使用できます。すべて管理パネルから設定できます。

スケーリングの問題がない限り、Redisを使い続けることをお勧めします。タグをサポートしており、遅いバックエンドとしてファイルまたはデータベースを使用するmemcachedよりもはるかに高速です。一貫したタグとクリーニングが必要な場合は、複数のWebヘッドがあるときにデータベースでmemcachedを使用する必要があります。Redisのタグサポートが組み込まれているので、心配する必要はありません。セッションにRedisを使用することもできます。

私はすべてのFPCについて話すことができますが、私たちのFPCでは、管理者を介してそれを保存する場所を設定できます。デフォルトのMagentoキャッシュバックエンドを使用するか、ファイル、データベース、APC、Redis、Memcache、および最適化されたファイルバックエンドのいずれかを使用するカスタム設定を指定することができます。

正解はありません。ストアには、サブ3秒の動的ページロードと、理想的には1-2秒の動的ページロードが必要です。1秒未満は不要であり、主にマーケティング主導の統計です。Apacheは習得が容易で実行が困難です。Nginxは習得が困難で実行が容易です。多くのサイトはNginxに移行していますが、NginxとMagentoに基づく高品質のアーキテクチャを持つことは簡単ではありません。

マルチサーバーMagentoクラスターは既に実装が複雑であり、正しいアーキテクチャ上でない場合は保守がさらに困難です。通常、ランキングを含めてすべてがよりスムーズに実行されるように、より大きなクラスターを使用します。1〜2秒の動的なページ読み込みをターゲットに、中長期の安定性を少し変更する標準インストール構成でこれを行います。これにより、メンテナンスがすべて簡単になります。

ワニスはFPC、CDNなどになりますが、あなたの場合はFPCと考えるのが最善です。FPCはサーバー上の訪問者を増やし、Varnishがそのようなツールの1つである静的配信を高速化しますが、動的コンテンツ、在庫管理、価格設定など、さまざまな問題があります。答えは、ビジネスの構造、データのロード方法、頻度、ホスティングタイプなどに依存し、訪問者に静的コンテンツを提供することでビジネスが影響を受けるだけです。FPC configを使用すると、これの多くを技術的に軽減できますが、ビジネス環境を複雑にします。ビジネスオーナーの観点からは、バランスの取れた投資収益率が得られない場合があります。

FPCは、サブ3秒以上の動的ローディングがある場合の最後の部分です。これは、ランキングに影響するため訪問者のリクエストのビーズを処理でき、マーケティングと休日のスパイクを吸収し、サーバーアーキテクチャの複雑さを追加する予算があります-ホスティングは0.5にする必要があります小規模ビジネスの収益の-1％。ほとんどの場合、これを大幅に下回っており、多くの間接的なビジネス問題を引き起こしています。

明確な答えを見つけられなかった理由は、これらの質問は定性的（ビジネスベース）であり、企業が公に投稿したくない情報を必要とするため、ページの読み込み速度は定量的（技術ベース） ）公開することができます、それはあなたがソリューションを作る2つを組み合わせる方法です。

このMagentoページキャッシュは、ニーズに合わせて使用でき、ニスに似ています。これは、最大のMagentoストアの多くで使用されています。いくつかの機能：

1. Varnishと同様、リクエストの90％でデータベース接続を使用しません。その結果、非常に高速です
2. 製品の在庫などが変化したときにページを自動フラッシュする機能があり、非常に優れています
3. これは多層キャッシュであるため、ユーザーがログインするときのホールパンチもサポートします（これらの要求にはデータベースの使用が必要です）

マルチレベルキャッシュとして、最高レベルのトラフィックストアでもスケーラブルであり、SharkTank（テレビ番組）で紹介されているストアなど、ピークトラフィックを受信する多くの非常にトラフィックの多いサイトで使用されています。