Communauté Magento francophone

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 :

http://fr3.php.net/apc

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

écrit par Gilles \\ tags: APC, opcode, performance, tuning

Durant nos différents échanges à Bargento, j’ai réévoqué la piste d’un « compilateur de site ».

C’est un projet qui peut prendre de multiples formes, du préloading d’un site pour rendre le cache du reverse proxy efficace immédiatemment ou encore appeler tous les liens avec une spider et sortir un site « Semi statique » à partir du site Dynamique originel.

Plusieurs personnes ont trouvé l’idée intéressantes, certains ont même déjà de l’expérience dans le domaine, un contributeur Drupal, l’admin du vendée Glob (de AFG je crois ?) un monsieur de chez Smile. Je n’ai pas retenu tous les noms ou toutes les bonnes volontées mais je suis prêt à créer un groupe de travail sur ce point avec les volontaires.

L’idée est la suivante :
Les langages interprétés comme PHP ne sont pas très optimisés pour les processeurs et leurs systèmes de cache.
Ce point peut se compenser en imaginant un site Web très dynamique (Zend/Magento par exemple) comme un « code source » de l’époque C++. Le but c’est que la version dynamique reste bien LA référence mais que pour des raisons de performances, ont « pré calcul », on compile, une partie des pages du site. Du coup, le serveur Web fournit des pages HTML et non plus du PHP qui génère du HTML. Le rapport de puissance peut aller de 1 à 10 sans problème, comprenez qu’un même serveur Web frontal pourrait servir 10000 connexions simultanées au lieu de 1000.

Outre le gain de performances et l’économie de puissance, on constate également que le surfer reçoit une information quasi immédiatemment puisque le serveur n’a plus à générer du HTML puis à l’acheminer mais juste à l’acheminer.

Les limites :
En premier lieu, ceci ne permet d’optimiser que les performances des serveurs Web. En effet, ce qui est allégé, c’est le temps de rendu des pages et uniquement ce point. Rechercher un produit dans une base de données pas optimisée n’ira pas plus vite qu’avant. En poussant le vice, on pourrait précalculer les réponses aux 3 recherches les plus fréquentes dans le moteur selon une espèce de règle des 80/20.

Ensuite, il ne faut pas oublier que le site doit être généré à une fréquence suffisamment élevée pour que les changements importants soient visibles rapidement. Il faut également le « compiler » sur un autre serveur que celui de production car sinon on va entacher ses performances lors de la génération des pages semi-statiques. En fait il faudrait même pouvoir recompiler le site à la demande, sur tout ou partie (les prix uniquement, les articles et les prix, juste une page, comme avec un Makefile en fait)

Les obstacles :
La complexité du projet réside dans le fait que de nombreux élements nécessitent l’affichage d’informations dynamiques. Le caddie d’une personne, ses « choix pour plus tard », les comparateurs de prix ou de produits etc… De même, interroger la base de données en faisant une recherche sur un site répondra forcément un contenu différent selon la recherche (sinon on risque de décevoir un peu le visiteur).

On ne peut pas non plus trop déporter le processus dynamique sur le poste client, cela peut dans certains cas engendrer des risques de sécurité. La business logic de traitement des commandes et ce genre de choses ne peut pas résider « customer side » dans la machine virtuelle javascript du browser sinon elle est aisée à corrompre.

Mais c’est un peu comme dans la pub pour une certaine carte de crédit :
« Il a ce que vous ne pouvez pas rendre statique, pour tout le reste, précompiler votre site ! »

Alors ? Faisable ou pas ? Utile ou juste une idée en l’air ? J’en appel aux volontaires pour qu’on voit si un petit groupe de travail souhaite se pencher efficacement dessus.

écrit par Philippe Humeau \\ tags: compilation, dynamique, optimisation, statique

écrit par Philippe Humeau \\ tags: amd, magento, mysql, shanghai

Mais oui, pourquoi au fait ?

Voici une analyse philosophico-technique d’une question existentielle qu’on se pose tous : « Pourquoi Magento est un gouffre de puissance ? »

En premier lieu, Magento dépend d’un autre framework : Zend. Et ce n’est pas le seul à être gourmand, les Ruby on Rail et autres sont aussi des affamés.

Pour revenir à Magento, c’est un framework de deuxième niveau, de l’objet d’objet. Or, revenons aux racines, à l’époque ou Stroustrup, Kernighan et Ritchie nous inventent l’objet et le C++. L’objet c’est une méthode de programmation pensée pour factoriser le code source, faciliter sa réutilisation ainsi que permettre à des humains de manipuler des concepts plus agréables que des (char *), des pointeurs et des librairies à rallonge.

Donc en gros, à partir du C, le C++ a été créé et d’autres langages ont suivi le même processus.

Mais… Car il y a (toujours) un mais, cette structuration objet est plus « lourde ». Simplifier, en général ca veut dire qu’en dessous quelqu’un a fait quelque chose de plus complexe pour vous simplifier la vie. Voyez ca comme un canard, calme en surface mais qui pédale dur en dessous. En objet c’est pareil, la simplicité pour l’humain a impliqué un code plus lourd à digérer pour la machine et puis si on fait des objets c’est bien pour développer des programmes plus utiles, complexes, effiaces etc… La programmation objet a donc une tendance naturelle à compliquer les choses pour la machine mais le compilateur, quand il est performant, réduit tout cela à un assembleur très comparable. Une même fonction en C et en C++ va fournir un code assembleur assez comparable pour que les performances soient proches. Le compilateur est plus complexe, il met plus de temps à compiler, mais l’éxécution du binaire ne sera qu’imperceptiblement plus lente, ce compilateur « gomme » donc la lourdeur engendrée par l’objet.

Résultat : c’est tout bénéfice, l’humain manipule des objets plus agréables et plus utilisables, se lance dans le fonctionnel au lieu d’avoir les mains dans le camboui (ceux qui ont fait du x86 savent de quoi je parle), la machine interprete une fois un peu plus longtemps avec son compilateur et au final, quand le programme se lance, il est aussi rapide !

Oui mais……… PHP n’est pas un langage compilé. C’est un langage interprété. Et la complexité supplémentaire pour la machine qui était gommée par le compilateur ne l’est plus. A chaque interprétation, on reprend le même code, on replonge dans les niveaux d’abstraction objets et on force le CPU a interpréter tout cela. Alors avec juste du PHP « non objet » ca allait encore. Avec du PHP 5, on attaque la notion d’objet, on s’alourdit un peu mais ca tient toujours la route. Avec Zend, c’est déjà nettement plus consommateur de ressources, on est sur une couche d’abstraction supplémentaire et ca comme à se sentir. Lire la suite »

écrit par Philippe Humeau \\ tags: compilé, interprété, langage objet

Comme nous allons parler essentiellement de performances et d’optimisation, il faut que nous convenions d’un vocabulaire commun et d’unité de mesure commune sinon cela va compliquer le dialogue et perturber les comparaisons. Je ne crois pas qu’il y ait réellement de normes en vigueur alors nous avons choisis, à plusieurs, d’utiliser le référentiel suivant :

Sessions Actives (SA) : nombre de personnes utilisant activement des ressources du serveur. Elles sont connectées et ont appuyées très récemment sur un bouton/lien/image, ce qui impose au serveur un traitement pour lui répondre, ou bien elles viennent de se connecter sur le site et attendent en retour la homepage. Lire la suite »

écrit par Philippe Humeau \\ tags: optimisation, vocabulaire