速度:APCとMemcachedの両方を使用したMagento


17

私たちは多くのフォーラムを研究してきましたが、次の答えを知りません。両方がAPCありMemcache、サーバーにインストールされています。正しい最適な構成が何であるかはわかりません。

私の質問

MemcacheとAPCの両方を同時に使用してMagentoを実行するのに最適な設定は何ですか?(またはこれはまったく賢くない)

背景調査

ここでは、MemcacheとAPCは高速キャッシュと低速キャッシュとして推奨されています(ただし、ディスクはありません)。このような音は、十分なRAMがある場合にのみ機能します(そして、それについて確実に)

この記事は、Memcache または APCについてのものです。

また、ここでは、Memcacheが本当​​に機能するのは、遅いバックエンドも定義されている場合のみであると述べています。

この記事は同じことを言っていると思います

これは、local.xmlに対するISPのソリューションです

<cache>
  <backend>apc</backend>
  <prefix>sitenamehere__</prefix>
</cache>
<cache>
  <backend>memcached</backend>
  <memcached>
    <servers>
      <server>
        <host><![CDATA[127.0.0.1]]></host>
        <port><![CDATA[11211]]></port>
        <persistent><![CDATA[1]]></persistent>
      </server>
    </servers>
    <compression><![CDATA[0]]></compression>
    <cache_dir><![CDATA[]]></cache_dir>
    <hashed_directory_level><![CDATA[]]></hashed_directory_level>
    <hashed_directory_umask><![CDATA[]]></hashed_directory_umask>
    <file_name_prefix><![CDATA[]]></file_name_prefix>
  </memcached>
</cache>

状況

共有ホスティングBrim FPCがインストールされている:http : //ecommerce.brimllc.com/full-page-cache-magento.html (このFPCには、より複雑にするためにスケーラブルなファイルキャッシュもあります)


@sonassi、なぜmemcached-tagの代わりではないのですか?code.google.com/p/memcached-tag

回答:


26

これら2つの製品の使用方法を理解するには、これら2つの製品の明確な区別を理解する必要があります。

  • APCはOPCodeキャッシュであり、高速バックエンドの
  • Memcacheは単なる高速バックエンドです

APCをOPCodeキャッシュとして使用する

サーバーにモジュールをインストールするだけです

pecl install apc

そして、あなたの中でそれを有効にします php.ini

echo "extension=apc.so" >> /usr/lib/local/php.ini       (RedHat/Centos)
echo "extension=apc.so" >> /etc/php5/conf.d/20apc.ini   (Debian)

次に、適切なランタイム構成を有効にして微調整します

apc.enabled
apc.shm_segments
apc.shm_size
apc.optimization
apc.num_files_hint
apc.user_entries_hint
apc.ttl
apc.user_ttl
...

次に、PHP / Apacheを再起動します

/etc/init.d/httpd restart                               (RedHat/Centos)
/etc/init.d/apache2 restart                             (Debian)

その後、他に行うことはありません。APCがクイックで有効になっていることを確認しphpinfo()ます-それ以外の場合、この時点では、APCのOPCodeキャッシュ部分はアクティブです。

Magento側で設定する必要はありません。

APCを高速バックエンドとして使用する

以下を追加する必要があります ./app/etc/local.xml

<global>
  ...
  <cache>
    <backend>apc</backend>
      <prefix>mystore_</prefix>
  </cache>
  ...
</global>

次に、既存のストアキャッシュをフラッシュします。動作していることを確認するには、フロントエンドでページをロードすると、./var/cacheディレクトリが空のままになります。

Memcacheを高速バックエンドとして使用する

MemcacheをPHP拡張機能としてインストールし、それぞれのMemcache Daemon(Memcached)をサーバーにインストールする必要があります。

pecl install memcache

php.iniで有効にします

echo "extension=memcache.so" >> /usr/lib/local/php.ini            (RedHat/Centos)
echo "extension=memcache.so" >> /etc/php5/conf.d/20memcache.ini   (Debian)

/etc/init.d/httpd restart                               (RedHat/Centos)
/etc/init.d/apache2 restart                             (Debian)

次に、Memcachedをサーバーにインストールします。RH / Centosの場合、リリースバージョンとCPUアーキテクチャに合わせてURLを調整します。

rpm -Uhv http://apt.sw.be/redhat/el6/en/x86_64/rpmforge/RPMS/rpmforge-release-0.5.2-2.el6.rf.x86_64.rpm
yum --enablerepo=rpmforge install memcached

apt-get install memcached                               (Debian)

次に、Magentoを修正してMemcacheを高速バックエンドとして使用し、ソケットパスをTCP / IP接続に合わせて変更します。

<cache>
  <slow_backend>database</slow_backend>

  <fast_backend>memcached</fast_backend>
  <fast_backend_options>
    <servers>
      <server>
        <host>unix:///tmp/memcached.sock</host>
        <port>0</port>
        <persistent>0</persistent>
      </server>
    </servers>
  </fast_backend_options>

  <backend>memcached</backend>
  <memcached>
  <servers>
    <server>
      <host>unix:///tmp/memcached.sock</host>
      <port>0</port>
      <persistent>0</persistent>
    </server>
  </servers>
</cache>

Memcacheとタグ付けの注意点- 保存するもの

Memcacheは単一レベルのキーと値の関係のみをサポートするため、Magentoキャッシュタグ(キャッシュデータを個別にフラッシュするために使用される)を保存できません。その結果、slow_backendキャッシュコンテンツタグの関係を維持するためにを指定するか、まったく定義しないでください。

を定義するslow_backendと、キャッシュタグが大きくなりすぎてパフォーマンスが低下するリスクがあります。各サーバーが独自のキャッシュタグを保持している場合、複数のサーバーにまたがってスケールできないという固有の問題もあります。

そのため、Memcacheを使用する場合のより良いアプローチ(注意点として、キャッシュを個別にフラッシュすることはできません)は、slow_backendです。

その場合、それを削除<slow_backend>database</slow_backend>して置き換えることをお勧めします:

  <slow_backend>Memcached</slow_backend>
  <slow_backend_options>
    <servers>
      <server>
        <host>unix:///tmp/memcached.sock</host>
        <port>0</port>
        <persistent>0</persistent>
      </server>
    </servers>
  </slow_backend_options>

これにより、キャッシングの第2レベルが中断/無効になります(タグの保存が防止されます)が、Memcacheのパフォーマンスは引き続き許可されます。

どちらを使用するか

単一サーバー展開の場合 -すべてにAPCを使用するだけで害はありません。

分散セットアップの場合 -Memcacheを高速バックエンドとして使用する必要があります(すべてのマシンが共通ストアにアクセスできるようにするため)。

さらに心配なのは、ホスティングプロバイダーが使用するための適切な設定を教えてくれない場合、間違いなくホストが間違っているということです。


属性:sonassi.comphp.netrepoforge.org


このトリックを使用してslow_backend_cacheを無効にしようとするとslow_backend must implement the Zend_Cache_Backend_ExtendedInterface interface、Mage 1.7.0.2になります
アーロンポロック

6

私は以前の回答にかなり同意しますが、ここにそれを完了するための短い精度があります:はい、apcはキャッシュストレージエンジンとしても、PHPバイトコードオプティマイザーとしても使用できます。ただし、2つの点を明確にする必要があります。

  • 高速バックエンドとして、APCがデータの保存方法を理解するために使用する構成ディレクティブは、apc.user_%ディレクティブを介して管理されます。その他は、バイトコードキャッシュのみに関係します(例apc.ttl:opcodeキャッシュの有効期限、apc.user_ttl:Magentoによってキャッシュに保存されたデータの有効期限)。

  • また、高速バックエンドとして、APCはmemcachedとまったく同じ動作をします。キャッシュタグを管理せず、Magentoの場合は構成済みの低速バックエンドが必要です(またはデフォルトで低速バックエンドファイルを使用します)。

私の経験から、大量のトラフィックがあるWebサイトで、apcをバイトコードオプティマイザーとしてのみ使用する場合、apc.shm_size構成値に96〜256Moが必要です。また、apc.num_files_hintを1000から15000に増やします。デフォルトでは、apcキャッシュバイトコードは1000ファイルのみをキャッシュし、Magentoにはデフォルトで約20,000のPHPおよびPHTMLファイルが含まれます(find . -type f -name "*.php" -o -name "*.phtml" | wc -l)。したがって、この値をソースコードでカスタマイズします。

APCまたはmemcachedを高速バックエンドとして使用する場合、必要なメモリに関するヒントを提供することは困難です。これは、インスタンスに適用されるキャッシュポリシーに依存します。

現時点では、キャッシュ構成は次のように機能します。

  • すべてのコンテンツは、memcachedとファイルの両方に保存されます
  • 低速バックエンドの前に常に高速バックエンドが要求されます
  • 高速バックエンドで何も見つからない場合、magentoは低速バックエンドで検索します

なぜこれらの2つのレベルの管理ですか?memcachedおよびその他の高速バックエンドはメモリストレージです。つまり、データが破損したり消失したりする可能性があるということです。

この構成のパフォーマンスを向上させるにはどうすればよいですか?

2番目の書き込みを無効にすることは、おそらく最も効率的なオプションの1つです。これについては、4番目の記事で説明しています。ただし、slow_backend_store_dataソースコードを変更せずに使用することはできません。あなたのコンテキストでは、次の理由でこのカスタマイズを行うことはお勧めしません。キャッシュに保存されたデータは制御されません。データをメモリに保存するとパフォーマンスが向上しますが、無効なコンテンツをビスタに送信する可能性があります。そのため、メモリアクセス(パフォーマンス向上)、書き込み制御、slow_backend_store_dataキャッシングを無効にする機能を確保するソリューションを見つける必要があります。次の方法でこのコンテキストにアクセスできます。

  • memcachedサーバーをredisサーバーに置き換え(redisはファイルシステムのように読み書きを制御できます)、バイトコードオプティマイザーとして apcを使用続けます

  • * ソースコードをカスタマイズするか、データベースのスローバックエンドに切り替えることで、slow_backend_store_dataオプションを使用できることを確認します(データベースサーバーの負荷を増加させますが、キャッシュポリシーが適切に定義されている場合、問題)

  • * slow_backend_store_dataオプションを非アクティブにします*:この構成ではもう必要ありません。redisによって読み取りおよび書き込み制御が行われます。


2

これに関する追加の注意事項として、MagentoでAPCを使用する場合(オペコードキャッシング用-従来のMagentoページおよびブロックキャッシング用にRedisを使用する場合)、本番環境ではstat設定が0であることを確認することが重要です(ただし、開発):

apc.stat = 0

apc.stat設定は、各リクエストでスクリプトをチェックして変更されているかどうかを判断するために使用されます(http://www.php.net/manual/en/apc.configuration.php#ini.apc.stat)そのため、実稼働環境でこれを0に設定すると、APCが各リクエストでこのチェックを行わないというパフォーマンス上の利点がもたらされます。

apc.statを0に設定すると、Webサーバープロセスを再起動してファイルの変更(つまり、展開後)を取得する必要がありますが、これはいずれにせよ展開後の戦略の一部であることに注意してください。


1

バックエンドを大幅に高速化するために行った最善の方法は、キャッシュハンドラーとしてREDISインストールすることです。Magento 1.8以降のコアでもサポートされるようになりました。

何も比較しない...今ではクリッククリッククリッカークリックです

http://www.magentocommerce.com/knowledge-base/entry/redis-magento-ce-ee

さらに、Redis Session拡張機能を追加して、Redisメモリサーバーにセッションを追加することも検討できます...

幸運を!


0

このlocal.xmlファイルから、Magentoは最後のエントリを取得し、Memcacheを使用します。APCとMemcacheがMagentoでどのように機能するかについては混乱があると思います。

まず、APCには2つの用途があります。

  • オペコードキャッシング-PHPファイルをオペコードにコンパイルし、スクリプトの実行を約25%高速化します
  • キー/値ストレージ-Magentoはキャッシュシステムとして使用できます。

一方、Memcacheは単なるキー/値ストアです。Memcacheの大きな利点は、クライアントサーバーモードで動作できるため、複数のフロントエンドサーバーが同じキャッシュを使用できることです。これは、同じWebサイトにサービスを提供するサーバーが複数ある場合に必要です。

最も一般的なセットアップは、APCをインストールしてオペコードキャッシングを取得し(したがって、スクリプトの実行を最大25%高速化)、Memcacheをキャッシュサーバーとして使用することです。また、キャッシュシステムとしてAPCを使用しましたが、理論上はMemcacheよりも少し高速になるはずですが、違いはわかりません。


したがって、私がこれを読んだ場合:最も一般的なセットアップは、APCをインストールしてオペコードキャッシングを取得し(したがって、スクリプトの実行が最大25%高速になる)、Memcacheをキャッシュサーバーとして使用することです。それでは、どうして両方を一緒に使用できますか?このようなものですか:coeusblue.com/blog/48-magento/65-magento-caching
snh_nl

両方を一緒に使用するには、APCに関係することをまったく宣言する必要はありません。
ベン・レッサーニ-ソナシ

それで、コードはすべてからでしょうか?<cache> <backend> memcached </ backend>の最初の部分は
省略します-snh_nl

加えて。私にとって、バックエンドの速度は常に全体の速度の尺度でした(FPCなどはここでは適用されないため)
...-snh_nl
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.