Vitesse: Magento avec APC et Memcached

Nous avons étudié de nombreux forums et ne connaissons pas la réponse aux questions suivantes. Nous avons les deux APCet Memcacheinstallés sur nos serveurs. Nous ne savons pas quelle est la configuration correcte et la meilleure.

Ma question

Quels sont / sont les meilleurs paramètres pour exécuter Magento en utilisant à la fois Memcache + APC? (Ou n'est-ce pas intelligent du tout)

Recherche en arrière plan

Ici, Memcache et APC sont recommandés comme cache rapide et lent (mais pas de disque). Cela ne fonctionne que lorsque vous avez suffisamment de RAM (et vous en êtes sûr)

• http://www.coeusblue.com/blog/48-magento/65-magento-caching

Et cet article concerne Memcache ou APC - et nous avons les deux

• http://magebase.com/magento-tutorials/speeding-up-magento-with-apc-or-memcached/

Et ici, il indique que Memcache ne fonctionne vraiment que lorsque vous avez également un backend lent défini

• http://www.magentocommerce.com/boards/viewthread/283908/#t393090

Et je pense que cet article dit la même chose

• http://www.byte.nl/blog/speeding-up-magento-the-burden-of-two-level-cache/

Ceci est la solution de mon FAI pour local.xml

<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>

Situation

Hébergement partagé Brim FPC installé: http://ecommerce.brimllc.com/full-page-cache-magento.html (ce FPC dispose également d'un cache de fichiers évolutif pour le rendre plus complexe)

Vous devez comprendre la distinction claire entre ces deux produits pour comprendre comment les utiliser.

• APC est à la fois un cache OPCode et un backend rapide
• Memcache est juste un backend rapide

Utilisation d'APC comme cache OPCode

Installez simplement le module sur votre serveur

pecl install apc

Et activez-le dans votre php.ini

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

Vous activez et affinez ensuite la configuration d'exécution en fonction, par exemple.

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

Redémarrez ensuite PHP / Apache

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

Après cela, il n'y a plus rien à faire. Confirmez qu'APC est activé avec un rapide phpinfo()- mais sinon, à ce stade, la partie de cache OPCode d'APC est active.

Rien n'a besoin d'être configuré du côté de Magento.

Utiliser APC comme backend rapide

Vous devez ajouter ce qui suit à votre ./app/etc/local.xml

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

Rincez ensuite vos caches de magasin existants. Pour vérifier que cela fonctionne, chargez une page dans le front-end et le ./var/cacherépertoire doit rester vide.

Utiliser Memcache comme backend rapide

Vous devrez installer Memcache en tant qu'extension PHP et installer le démon Memcache respectif (Memcached) sur votre serveur.

pecl install memcache

Et activez-le dans votre 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)

Installez ensuite Memcached sur le serveur. Pour RH / Centos, ajustez l'URL en fonction de votre version et de l'architecture du processeur.

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)

Ensuite, modifiez Magento pour utiliser Memcache comme backend rapide, changez le chemin du socket en une connexion TCP / IP à votre convenance.

<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>

Les mises en garde de Memcache et du tagging - qu'est - ce qu'il stocke

Memcache ne prend en charge qu'un seul niveau de relations clé-valeur, il ne peut donc pas stocker les balises de cache Magento (qui sont utilisées pour vider les données de cache indépendamment). Par conséquent, vous devez soit spécifier un slow_backendpour maintenir la relation de balise de contenu de cache, soit n'en définir aucun.

Si vous définissez un slow_backend , vous courez le risque que les balises de cache deviennent si grandes que les performances soient annulées; il y a aussi le problème inhérent que vous ne pouvez pas évoluer sur plusieurs serveurs si chaque serveur gère ses propres balises de cache.

Donc, lorsque vous utilisez Memcache, la meilleure approche (avec la mise en garde que vous ne pouvez pas vider les caches indépendamment), est de ne pas prendre la peine d'utiliser le slow_backend.

Dans ce cas, nous vous suggérons de le supprimer <slow_backend>database</slow_backend>et de le remplacer par:

  <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>

Cela interrompra / désactivera le 2e niveau de mise en cache (et empêchera le stockage des balises), mais permettra toujours les performances de Memcache.

À utiliser

S'il s'agit d'un déploiement sur un seul serveur - il n'y a aucun mal à utiliser APC pour tout.

S'il s'agit d'une configuration distribuée, vous devrez utiliser Memcache comme backend rapide (pour que toutes les machines puissent accéder au magasin commun).

Plus inquiétant, c'est que si votre hébergeur ne peut pas vous dire la bonne configuration à utiliser, vous êtes certainement avec le mauvais hôte.

Attributions: sonassi.com , php.net , repoforge.org

Je suis tout à fait d'accord avec les réponses précédentes, mais voici une courte précision pour le compléter: Oui, apc peut être utilisé à la fois comme moteur de stockage en cache et comme optimiseur de code octet PHP. Mais deux points doivent être clarifiés:

• En tant que backend rapide, les directives de configuration utilisées par APC pour comprendre comment il doit enregistrer les données sont gérées via les directives apc.user_%. Les autres ne concernent que le cache de code octet (Ex apc.ttl: la durée d'expiration du cache opcode, apc.user_ttl: la durée d'expiration des données stockées en cache par votre Magento).

• Et en tant que backend rapide, APC a exactement le même comportement que memcached: il ne gère pas les balises de cache, et pour Magento, il nécessite un backend lent configuré (ou utilise par défaut le fichier de backend lent).

D'après mon expérience, sur les sites Web à fort trafic, si vous utilisez apc comme optimiseur de code octet uniquement, vous avez besoin entre 96 et 256 Mo dans la valeur de configuration apc.shm_size. Augmentez également l'apc.num_files_hint de 1000 à 15000: par défaut, le cache de code d'octet du cache apc ne contient que 1000 fichiers et Magento contient environ 20 000 fichiers PHP et PHTML par défaut ( find . -type f -name "*.php" -o -name "*.phtml" | wc -l). Personnalisez donc cette valeur avec votre code source.

Si vous utilisez APC ou memcached comme backend rapide, il est difficile de vous donner quelques conseils sur la mémoire requise: cela dépend vraiment de la stratégie de cache appliquée à votre instance.

Pour l'instant, votre configuration de cache fonctionne comme ceci:

• chaque contenu est stocké à la fois dans memcached et dans un fichier
• Le backend rapide est toujours demandé avant le backend lent
• si rien n'est trouvé dans le backend rapide, magento recherche dans le backend lent

Pourquoi ces deux niveaux de gestion? memcached et d'autres backends rapides sont des stockages de mémoire. Cela signifie donc que les données peuvent être corrompues ou avoir disparu.

Comment pouvez-vous augmenter ces performances de configuration?

Désactiver la deuxième écriture est probablement l'une des options les plus efficaces. Ceci est expliqué dans le quatrième article que vous avez mentionné. Mais vous ne pouvez pas utiliser sans modifications le code source slow_backend_store_data. Dans votre contexte, je déconseille de faire cette personnalisation pour les raisons suivantes: vos données stockées en cache ne seront jamais contrôlées. Vous stockerez des données en mémoire, gagnerez des performances, mais enverrez peut-être à vos visiteurs un contenu non valide. Vous devez donc trouver une solution qui vous garantisse un accès à la mémoire (pour de meilleures performances), un contrôle en écriture et la possibilité de désactiver la mise en cache slow_backend_store_data. Vous pouvez accéder à ce contexte en:

• remplacer le serveur memcached par un serveur redis (redis peut contrôler la lecture et l'écriture comme cela est fait par un système de fichiers), et continuer à utiliser apc comme optimiseur de code d'octet

• * assurez-vous que vous êtes en mesure d'utiliser l'option slow_backend_store_data * soit en personnalisant votre code source, soit en passant à un backend lent de base de données (oui, cela augmente la charge de votre serveur de base de données, mais si votre politique de cache est bien définie, elle ne devrait pas être un problème)

• * désactiver l'option slow_backend_store_data * : dans cette configuration ce n'est plus nécessaire, vous avez le contrôle en lecture et en écriture fait par redis.

En plus de cela, nous avons constaté que lorsque vous utilisez APC avec Magento (pour la mise en cache d'opcode - nous utilisons Redis pour la mise en cache de pages et de blocs Magento conventionnelle), il est important de s'assurer que le paramètre de statistique est 0 en production (mais 1 dans développement):

apc.stat = 0

Le paramètre apc.stat est utilisé pour déterminer s'il faut vérifier un script à chaque demande pour déterminer s'il a été modifié ( http://www.php.net/manual/en/apc.configuration.php#ini.apc.stat ) et la définition de ce paramètre à 0 dans un environnement de production apportera l'avantage de performances d'APC ne pas effectuer cette vérification à chaque demande.

Il convient de noter qu'une fois apc.stat défini sur 0, vous devrez probablement redémarrer le processus de votre serveur Web pour détecter les modifications de fichiers (c'est-à-dire après le déploiement), mais cela devrait de toute façon faire partie de votre stratégie de post-déploiement.

La meilleure chose que nous ayons faite pour accélérer considérablement le backend est de installer REDIS en tant que gestionnaire de cache . Il est désormais également pris en charge dans le noyau à partir de Magento 1.8 et versions ultérieures.

Rien ne se compare ... maintenant c'est click click clickerdy ​​click

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

De plus, vous pouvez envisager d'ajouter l'extension Redis Session pour ajouter également des sessions au serveur de mémoire redis ...

Bonne chance!

À partir de ce fichier local.xml, Magento récupérera la dernière entrée et utilisera Memcache. Je pense qu'il y a une confusion entre la façon dont APC et Memcache peuvent fonctionner avec Magento.

Tout d'abord, APC a 2 utilisations:

• mise en cache d'opcode - compilez vos fichiers php en opcode, ce qui rend l'exécution du script environ 25% plus rapide
• stockage clé / valeur - peut être utilisé par Magento comme système de cache.

Memcache, d'autre part, n'est qu'un magasin de clés / valeurs. Le grand avantage de Memcache est qu'il peut fonctionner en mode client-serveur, donc plusieurs serveurs frontaux peuvent utiliser le même cache, ce qui est indispensable si vous avez plusieurs serveurs qui desservent le même site Web.

La configuration la plus courante consiste à installer APC pour obtenir la mise en cache des opcodes (vous obtenez ainsi une exécution de script ~ 25% plus rapide) et à utiliser Memcache comme serveur de cache. J'ai également utilisé APC comme système de cache et bien qu'en théorie, il devrait être un peu plus rapide que Memcache, vous ne pouvez pas faire la différence.