CE 1.8のフルページキャッシュ - FPC Magentoモジュール？ワニス？両方？
https://magento.stackexchange.com/questions/13957
-
16-10-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russian質問
だから、コミュニティエディション1.8のフルページキャッシングを調査しようとしているので、私は少し混乱しています。私はすでに2つのレベルのRedisキャッシュ、CDN、調整されたMySQLのMy.cnfを最大パフォーマンス（もちろん別のサーバー上にあるDB）を実装しており、ロードバランサーの後ろにストアをホストする2つのサーバーがあります。私は、最初のパフォーマンスの調整を行う前に、私がすぐにFPCにジャンプしていないことを指摘するために言います。
Magentoはもちろんのこと、あらゆる種類のサイトでワニスを使用したことがなく、MagentoでFPCを設定したこともありません。私は、ワニスがCDNとページキャッシュの間のクロスとして機能するプロキシであることを理解しており、リクエストがWebサーバーに到達する前にブラウザにデータを送信します。そして、私の理解のために、FPCモジュールは、ウェブサーバー自体が食い物になるようにローカルにキャッシュを作成します。両方のセットアップでは、動的なコンテンツをブラウザに届けるには「ホールパンチ」を実行する必要があることを知っています（ただし、テクニックは、モジュールを使用するか、ワニスを使用するかの間で異なります）。ここで何か誤解している場合は修正してください。
今まで、私はそれらをあなたがそれを実装できる2つの別々のエンティティと考えていました。私の元の計画は、「Warp Advanced Full Pageキャッシュ「Magentoのモジュール（以前は「小さなブリックライトスピードFPC」だったと思います）が最も人気があるように思えます。私と2人の仲間の開発者は、私たちが得ることができるものを最大化するために、私たち自身の慣習で自家製のテーマの中でそれを適切かつ完全に実装することを学ぶことを計画していました。道、私はワニスの実装も検討すると考えました - しかし、先ほど言ったように、私はそれらが別々であることを理解していました。
しかし、今では、このpagecacheのような拡張機能が無料の拡張機能、または800米ドル近くのワニスキャッシュを搭載したこの渦キャッシュに出くわし始めています。
Stack Exchange、あなたへの私の質問は、どのようにFPCとワニスを見るべきかということです。別々のエンティティとして？もしそうなら、それらは相互に排他的ですか？彼らは私が一緒に実装する必要があるのと同じコインの2つの側面ですか？それとも、それらは似ていますが、互いに排他的でも包括的でもありませんか？
上記で述べたワープアドバンスドFPCをワニスで使用できますか？ したほうがいい ワニスで使用しますか？または、ワニスを使用する予定がある場合は、別のFPCを使用する方が良いでしょうか？それとも、FPCが非常に良いので、ワニスは必要ありませんか？または、その逆も、ワニスを使用してFPCのアイデアを捨てるべきですか？
テキストの壁には申し訳ありませんが、私は多くの記事、ブログ、フォーラムの投稿を見てきましたが、それらの質問に対する決定的な答えを識別することはできませんでした。私はこの問題であなたの助けと入力に本当に感謝しています=）
ああ、最後に、ワニスとウェブサーバーについての簡単な質問。現在、私は通常のApache Lampスタックのセットアップを使用していますが、しばらくの間、MagentoでNginxを使用することを絶賛しているのを見てきました。私は自分でいくつかのテストを行った、ストレスと負荷テストを行ったことがありますが、適切な条件では間違いなく少しうまく機能するようです。そのため、近い将来のある時点で切り替えを検討していました。とにかく、これはFPCおよび/またはワニスを使用するという私の欲求と決定に影響しますか？
ありがとうございました！！！
編集：ああ！もう1つの簡単な質問 - ロードバランサーの背後にある2つのサーバーが私のサイトをホストしているので（これは必要に応じて水平に増加する可能性のあるセットアップです）、RedisとMemcachedを完全に使用し、別のサーバーでホストされています。私のセッションとMagento（まあ、Zendの）の2つのレベルのキャッシュの各レベルのWebとDBのもの。 FPCはデータをシステムの1つに保存すると思いますか？そこに保存するために特定の拡張機能が必要ですか、それとも彼らはすべてそれをしますか？そして、私はそうではないと思いますが、これはとにかくワニスに影響するでしょうか？再度、感謝します！！
解決
コンピューターサイエンスには2つの難しいことがあります。
- 物事の名前
- キャッシュ無効化。
ホールパンチングはカテゴリ＃2に分類されます:)
全般的
最良のアプローチは、スタックの下部ポイントから開始し、Magentoのフロントエンドまで最適化することです。
データベースとファイルシステム
常に焦点を当てる最初の領域である必要があります。なぜなら。 I/o。
マイトップ Linuxの「TOP」コマンドを模倣し、MySQLインスタンスの状態に関する洞察を提供する便利なLinuxベースのPerlスクリプトです。
htop aです より堅牢なトップ, 、 ストラス 機能は、潜在的なボトルネックを見つけるプロセスのイン/アウトを決定するのに役立ちます。
IoTop I/Oを監視するために考慮する別のツールです。
その他の便利なユーティリティスクリプトのようです mysqltuner.pl と MySQL Tunningプライマー MySQLランタイム変数についての洞察を提供し、ヘルプへのアドバイスを提供できます。最良のアプローチは常に要件の評価と収集されたデータに基づいた調整の評価であるため、これらはガイドであることを意図していることに留意してください。盲目的にそうすることは、良いよりも多くのダメージを引き起こす可能性があります。少なくとも24時間のMySQLランタイム変数なしでこれらを早期に実行すると、悪いアドバイスが提供される場合があります。
留意してください Percona, 、Mariadbと標準のMySQLは、上記のすべてと連携する必要があります。 MagentoはInnodbで非常に重いため、MySQLフォークとしてPerconaを好み、XtradbはDBエンジンに多くのツールと拡張機能を提供しています。
Apacheまたはnginx
私自身も含めて、他の多くのものに役立っているので、まだApacheを使用しています。 nginxも使用して構成しました。いくつかの利点を提供しますが、学習曲線があります。 2つは両方とも一般的なオプションですが、Apacheよりもいくつかの利点を提供しますが、1つはより小さなメモリフットプリントになります。ただし、PHP-FPMを実行しているスリムダウンアパッチは、同様のメモリフットプリントを持ちます。
適例：
この記事はパフォーマンスに関するものなので、Apacheが独自の方法から抜け出すのを支援する最も簡単な方法の1つは、.htaccessファイルを使用しないことであることを指摘する必要があります。ディレクトリスタンザに置いたものを置き、AllowoverRideを「なし」に設定すると、Apacheがドキュメント全体を通過するように依頼して、.htaccessに注意を払う必要があるかどうかを把握することになりません。これは、多くの人が見逃しているように見える基本的で簡単なチューニングのヒントです。
このチェックアウトを促進するのに役立ちます：
CDNを使用してどちらかを使いやすくするのに役立つことは明らかに役立ちますが、ほとんどのエンドユーザーブラウザは同じ数の接続制限で両方のサーバーに接続できるため、FrontEndの最適化に利点が追加されます。これにより、Apacheは、単純な静的画像を提供するためだけにチェックなどをジャンプする必要がないことから解放されます。 lighthttpd CDN以外のコンテンツだけで静的Webサーバーを実行する場合はオプションです。
Php
PHP-FPMおよびAPC。それらを使用して、Magentoに必要ではない不必要なまたは再免除されていないPHPモジュールを取り除きます。
Magento CodeBase
aoe_templatehints ブロックが適切にキャッシュしているかどうかを判断するのは素晴らしいことです。
- https://github.com/fbrnc/aoe_templatehints
- http://www.fabrizio-branca.de/magento-advanced-template-hints-20.html
aoe_profiler プロファイリングに適しています。DBレイヤープロファイリングを確認して有効にしてください（明らかにローカル/開発環境で）。これはと連携して マイトップ 前述のツールは、悪い動作を見つけるSQLを見つけやすくします。
サードパーティモジュールとカスタムコード
Magento自体からの最適化のためのいくつかの非常に優れたベストプラクティスは、よく読むことであり、それらを使用する前にサードパーティモジュールをレビューする際に留意してください。 （悪い振る舞いのあるものがたくさんありますIMO）。
Magento ECGのツールマグニファーは、上記のPDFに基づいて、動作の悪いコードを簡単に識別するのに役立ちます。ただし、Symfony/PHP-Parserベースですが、Composerを介してインストールできます。
ワニス
著者であるワニスがfreeBSDカーネル開発者であるという擁護者として、それはいくつかのクレイジーなサブ2番目の負荷時間を提供します。ただし、箱から出していないテンプレートにわずかな違いがある場合、必要なコンテンツをホールパンチするためにワニス /マゼントを構成するのに時間を費やします。私が見たほとんどの人は、ワニスから不要な必要なアイテムを単に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）
一日の終わりに 独自のテストと判断を使用してください。
さらに読む：
他のヒント
私が知っているこのスレッドに少し遅れていますが、あなたがまだ解決策を探しているなら、あなたは考慮したいかもしれません、 進化したキャッシュ. 。ワープと同じ価格ですが、それ：
- 非常に迅速かつ簡単にインストールして構成できます - すべてのホールパンチングと構成は管理者内から行われます
- ワニスと直接統合し、Magento内からワニスキャッシュをクリアして温めることができます
- 西暦1.8に導入されたFrontEnd formkeyで動作します。
- 応答性の高いサポートで非常に積極的に開発されています。レポートから数日以内にバグ修正をリリースすることを目的とした通常の新しいバージョン
- 広範です ドキュメンテーション リリースごとに更新されます
ワニスでのセットアップは簡単です。管理設定を有効にして、見つかった.vclを使用するだけです。 ここ. 。また、通常のようにCookieが存在しない場合にのみキャッシュを提供するワニスに限定されません - 非常に高いキャッシュヒット率が得られます。
Magento 1.8の新しいフォームキーと互換性のあるFPCを作成しました。 Brimのフルページキャッシュ： http://ecommerce.brimllc.com/full-page-cache-magento.html
ブーマーは、スタックで低く始めて、あなたの道を歩むことについて大きなポイントを語っています。 FPCまたはワニスは、あなたがする最後のものでなければなりません。パフォーマンス監査を行い、一般的にMySQLおよびAPC構成の問題を見つけます。 INNODBバッファサイズがデフォルトに設定されているように、データベースはそれをはるかに超えて成長しています。
特に協力するように設計されていない限り、ワニスでFPCを使用することをお勧めします。一般的に、コードベースと一緒にチューニングされていて、まだトラフィックを維持するのに苦労しているいくつかのビーフサーバーがない限り、ワニスをお勧めしません。リクエストをMagentoバックエンドに制限し、順番に負荷を削減しようとする場合、特にワニスで動的コンテンツを更新することは難しい場合があります。 1つまたは2つのWebヘッドがある場合、利益は時間と複雑さの価値がないかもしれません。
ほとんどの場合、優れたFPCは、もちろんサーバーとコードベースが調整された後、あなたのニーズをパフォーマンスします。 FPCを使用すると、レベル1キャッシュでサブ15msの発電時間を取得し、標準キャッシュで100msサブを取得できます。レベル1のキャッシュは、ユーザーがログインしておらず、カートに穴のパンチがないため、カートに何もない場合に使用されます。これらの条件のいずれかが誤っている場合、標準のキャッシュは完全なホールパンチサポートで使用されます。
FPCには簡単なホールパンチが組み込まれており、すべての標準的なMagentoブロックとカスタムブロックを備えた箱から出しています。すべて管理パネルを介して構成可能です。
スケーリングの問題が発生していない限り、Redisに固執することをお勧めします。タグサポートがあり、遅いバックエンドとしてファイルまたはデータベースでMemcachedよりもはるかに高速です。一貫したタグとクリーニングが必要な場合は、複数のWebヘッドがあるときにデータベースでMemcachedを使用する必要があります。 Redisのタグサポートが組み込まれているため、心配する必要はありません。また、セッションにRedisを使用することもできます。
私はすべてのFPCについて話すことができますが、私たちと一緒に、あなたはそれを保存する場所を管理する場所を構成することができます。デフォルトのMagentoキャッシュバックエンドを使用するか、ファイル、データベース、APC、Redis、Memcache、および最適化されたファイルバックエンドのいずれかを使用するカスタム設定を指定することを選択できます。
正解はありません。ストアには、サブ3の動的ページのロードと理想的には1〜2秒の動的ページのロードが必要です。サブ秒は必要ありません。主にマーケティング駆動型の統計です。 Apacheは学習が容易で、パフォーマンスを作るのが難しく、Nginxは学習が難しく、パフォーマンスを簡単に作成できます。多くのサイトはNginxに移動していますが、NginxとMagentoに基づいた高品質のアーキテクチャは簡単ではありません。
マルチサーバーのMagentoクラスターは、すでに実装するのが複雑であり、正しいアーキテクチャではない場合はさらに維持するのがさらに難しく、通常、すべてがランキングを含めてよりスムーズに実行される大きなクラスターを使用します。これは、1-2秒の動的ページロードを対象とした中期安定性のためのマイナーな変更を備えた標準インストール構成でこれを行います。これにより、メンテナンスのためにすべてがはるかに簡単になります。
ワニスはFPC、CDNなどですが、あなたの場合はFPCと考えるのが最善です。 FPCにより、サーバー上のより多くの訪問者が可能になり、そのようなツールの1つであるワニスがより高速な静的配信を提供しますが、動的なコンテンツ、在庫管理、価格設定など、さまざまな問題があります。答えは、ビジネスの構造、データのロード方法、頻度、ホスティングタイプなど、訪問者に静的コンテンツを提供することでビジネスの影響を受けます。 FPC構成でこれの多くを技術的に軽減できますが、ビジネス環境を複雑にします。ビジネスオーナーの観点からは、バランスの取れた投資収益率を生み出すことはできません。
FPCは最後の部分です。サブ3以下の動的荷重がある場合、アーキテクチャはランキングに影響を与え、マーケティングと休日のスパイクを吸収し、サーバーアーキテクチャに複雑さを追加する予算があるため、訪問者要求のビードを処理できます。小規模企業の収益の1％は、ほとんどがこの下で実質的に実行され、多くの間接的なビジネスの問題を引き起こしています。
決定的な答えを見つけていない理由は、企業が公開したくない情報を必要とする定性的（ビジネスベース）であるため、回答するのに数か月かかるという事実によるものです。ページの負荷速度は定量的です（技術ベースです）Publicyを投稿できる、それはあなたが解決策を作る2つを組み合わせる方法です。
これを使用できます Magentoページキャッシュ あなたのニーズに合わせて、ワニスに似ています。最大のマゼントストアの多くで使用されています。いくつかの機能：
- ワニスと同様に、リクエストの90％にデータベース接続を使用しません。その結果、非常に高速です
- 製品在庫のようなものが変更されたときにページを自動フラッシュする機能があり、それは非常に優れています
- これは多層キャッシュであるため、ユーザーがログインするとホールパンチもサポートします（これらのリクエストはデータベースの使用が必要です）
マルチレベルのキャッシュとして、それは最高の交通店舗でさえスケーラブルであり、Sharktank（TV Show）で紹介されている店舗などのピークトラフィックを受け取る非常に高い交通サイトで使用されています
