Bonjour à tous,
Ce post va traiter de l’optimisation de l’Opcode APC.
Pour plus d’informations sur APC, ci dessous, un lien de présentation :
Dans ce document, nous allons aborder quelques points de réglage. Pour ma part, j’estime qu’il procure un gain au niveau du temps d’accès de la page d’accueil de l’ordre de 0,15s (0,40s vs 0,25s), le tuning a amélioré le temps de réponse de 0.05s. En charge, je pense que les réglage on permis d’augmenter la charge sur le serveur avec un facteur 3.
Je n’ai pas de statistiques exactes sur ce point car j’ai modifié 4 tables dans la base Mysql pour optimiser les performances et diminuer les points de blocage.
Les modifications combinées ont permis de diminuer la charge CPU par 10. (avant les modifications, un test de charge de 200 utilisateurs a fait monter la charge CPU à 100. Le même test de charge avec les réglages que je vais présenter et le changement de 4 tables du type MyISAM au type innodb n’a fait monter la charge CPU qu’à 10).
Tout d’abord, je tiens à préciser que je n’ai rien inventé, j’ai effectué quelques recherche et j’ai ensuite testé.
La référence de mon étude se base sur cet article : http://julien-pauli.developpez.com/tutoriels/php/apc/
La première chose que j’ai faite est la mise à disposition de la page apc.php fournie dans le package pecl d’installation. Cette page php permet d’effectuer un diagnostic de l’état d’APC, notamment de savoir comment il est utilisé.
Par défaut, la taille du cache est de 30Mo, ce qui semble suffisant pour la majorité des applications. De mon coté, j’ai estimé qu’il n’était pas suffisant car j’ai la mémoire utilisée à 95%, voir un peu plus et une très forte fragmentation. La fragmentation est un signe qui m’a indiqué que des fichiers sont régulièrement sortis du cache pour en mettre d’autres. L’autre paramètre qui m’a indiqué que des fichiers n’étaient pas cachés est la statistique « hit and misses », cette statistique etati à 50% de hit. Le simple fait d’augmenter la taille du cache a résolu la fragmentation et mes statistiques de hit & misses sont maintenant proche de 100% de hit (900000 hits vs 300 misses).
J’ai continué mes recherches en parcourant l’article ci dessus et j’ai testé quelques réglages conseillés :
apc.num_files_hint
apc.user_entries_hint
Ci dessous, les réglages spécifiques que j’ai apportés :
apc.shm_size = 128
apc.stat = Off
apc.include_once_override = 1
apc.num_files_hint = 0
apc.user_entries_hint = 0
apc.max_file_size = 2M
Toutes ces fonctions sont détaillés dans la documentation php :
http://fr3.php.net/manual/fr/apc.configuration.php
février 11th, 2009 at 14 h 03 min
Je profite de son article pour accueillir Gilles dans le lineup éditorial de Wikigento. Merci Gilles pour ce retour sur APC Cache et par avance pour tes futurs articles !
février 11th, 2009 at 16 h 24 min
Je rajoute à cet article qu’il est possible de gagner ENORMEMENT de perf grâce à APC en cachant les blocs complet de rendu phtml, comme par exemple le listing produit ou une fiche produit.
Par défaut dans MAGENTO seul le bloc footer utilise cette technique, mais il est possible de l’étendre à tous les blocs, la difficulté étant de trouver un identifiant unique (je me sers pour le moment de l’URI de la requête).
février 14th, 2009 at 11 h 43 min
@Julien : peux-tu donner plus d’informations sur ton astuce ? Merci !
février 17th, 2009 at 15 h 34 min
Philippe m’aurais-tu oublié ?
Je plein de choses à dire moi aussi.
D’ailleurs j’aimerai bien commencer par la communication Magento interlogiciel via le webservice ce ferai un bon petit sujet.
février 17th, 2009 at 20 h 37 min
L’idée est de faire un module de ce style :
class LJ2_Catalog_Block_Product_List extends Mage_Catalog_Block_Product_List
{
protected function _construct()
{
$this->addData(array(
‘cache_lifetime’ => false,
‘cache_key’ => false,
));
}
public function getCacheKey()
{
$ret = Mage::app()->getStore()->getId() . ‘_’.$this->getTemplate().’_’.$this->getRequest()->getRequestUri();
return $ret;
}
}
février 18th, 2009 at 18 h 25 min
Je te crée ton compte d’auteur dès demain !
février 23rd, 2009 at 13 h 47 min
Attention à l’utilisation de APC sur des environnements mutualisés.
Si les versions de magento ou du code mis en cache diffère, il faut bien faire attention à ce qui est en cache. Il peut y avoir des effets indésirables.
février 23rd, 2009 at 17 h 03 min
Oui, de plus, pour un environnement mutualisé, il faut pouvoir remettre les caches (APC, Rproxy, cache Zend/Magento) de chacun des sites à zéro sans impacter les autres.
février 15th, 2010 at 18 h 51 min
Lorsque vous utilisez APC, PHP est lié comment à Apache ?
Je teste une nouvelle config avec Apache2, PHP5 mode CGI avec Fast-CGI
Je viens d’installer APC (cache).
J’ai un fichier php avec juste un phpinfo() et lorsque je consulte le
résultat de cette page, ça fonctionne une fois sur 2 (exactement 1x/2).
Quand ça ne fonctionne pa,s ça crée une internal server error dont les
logs apache donnent :
Mon Feb 15 18:17:41 2010] [warn] (104)Connection reset by peer:
mod_fcgid: read data from fastcgi server error.
[Mon Feb 15 18:17:41 2010] [error] [client 88.185.142.xxx] Premature
end of script headers: t.php
[Mon Feb 15 18:17:44 2010] [notice] mod_fcgid: process
/home/machin/www/t.php(20716) exit(communication error), get
unexpected signal 11
Avez-vous une idée de ce qui se passe ?
février 16th, 2010 at 11 h 24 min
Bonjour
@Julien,
APC est un module pecl de php. Infos ici :http://pecl.php.net/package/APC
Par contre, les messages d’erreurs que tu a ci dessus n’ont rien à voir. Il peut y avoir un probleme de configuration de php en mode fast cgi.
Gilles
mars 6th, 2010 at 14 h 45 min
Bonjour
Je teste actuellement APC et je rencontre parfois des problème de montée en charge du serveur. Par moment cela fonctionne correctement et puis un laps de temps plus tard mon fichier apc.php indique aucun fichier en cache et un Cache full count élevé.
Quand j’ai cette situation : des pages articles mette 8-10 sec à s’afficher au lieu des 1sec
Je n’avais pas de montée en charge moyenne avant l’installation de APC. Celle-ci était basse
Dois je ajouter la configuration ci-dessous au php.ini ?
[apc]
apc.ttl= »7200″
apc.user_ttl= »7200″
apc.shm_segments= »3″
apc.shm_size= »128″
mars 8th, 2010 at 10 h 12 min
Ça sent le problème d’I/O à plein nez. Vous pourriez faire un cat /proc/interrupts et voir si les I/O des disques sont bien réparties sur tous les coeurs où si elles sont toutes scotchés à 99% sur le même ? On a eu le soucis de notre coté aussi et ca bloquait les autres cœurs quelques secondes le temps que le controlleur SAS finissent d’écrire sur le disque. Ce n’était donc pas directement lié à APC mais à un soucis de gestion des interrupts par le kernel.
Pour voir en live ce qui fait scotcher les cœurs : mptstat -P all 1
Si c’est bien celà, c’est un problème de gestion des affinités des IRQ sur les processeurs SMP. On a déclaré l’entrée chez plusieurs constructeurs (dont Dell) sous le titre « IRQ affinity problem on SMP ». ca doit venir de là : kernel/irq/manage.c et de là arch/x86/kernel/apic/io_apic.c. Le patch kernel est en cour d’élaboration et sinon, une carte controlleur avec du cache pourra décoincer le problème.
mars 24th, 2010 at 13 h 36 min
Depuis que j’ai ajouté ces lignes au php ini :
apc.ttl=”7200″
apc.user_ttl=”7200″
apc.shm_segments=”3″
apc.shm_size=”128″
Je n’ai plus le problème