Je vais me faire des amis avec un titre comme celui-là

Maintenant, au-delà de la provoque, menons une analyse objective.

Nous avons, de nos jours, (au moins) deux gros goulots d’étranglement lorsque nous nous adressons à un site Web :

• Javascript du coté du client
• PHP du coté du serveur.

Analyse…

Parlons de Javascript…

En général, je m’intéresse plus aux performances des serveurs que des clients au sens « navigateurs ». En réalité, la performance des clients est en générale très liée à celle des serveurs pour être plus précis. Mais le serveur ne peux pas toujours tout.

Notamment les browsers encaissent plus ou moins bien le Javascript et surtout beaucoup de Javascript.

Opera, Chrome, Firefox, Internet Explorer et leurs copains ont une tendance très nette à réagir différemment (je n’apprends rien aux développeurs Web) et surtout à réagir plus ou moins bien et plus ou moins vite en interprétation de Javascript. De plus, ces différences se cumulent avec des comportements très différents d’un browser à l’autre, notamment le nombre de requêtes concurrentes (nombres d’éléments de la page chargé en parallèle).

Tous les sites récents utilisent énormément de Javascript et ont donc une belle tendance à charger la mule, surtout quand on a plusieurs onglets d’ouverts sur plusieurs sites, on a tout de suite des machine virtuelle javascript au sein des navigateurs qui se mettent à grossir.

Ok, so what ? Qu’est ce que j’y peux me réponde les développeurs…

Eh bien beaucoup de choses en fait. Déjà, un framework c’est bien mais ca n’empêche pas de réfléchir. Faire confiance aveuglément sans regarder le dessous des cartes, c’est ce qui mène au gâchis de ressources.

Optimiser ces points (comme d’autres), c’est ce que j’appelle la « culture atari / amiga ». En gros, à l’époque, les développeurs avaient des machines identiques, des machines avec des limites et on pensait à tirer le meilleur partie du Hardware, on optimisait son programme à la goutte prêt, on passait au plus proche du matériel pour faire des choses que les concepteurs de ces machines n’avaient même pas imaginé.

De nos jours, on prend un framework, on instancie un objet et hop, derrière ca pédale mais c’est plus mon problème… Revenons à Javascript.

Des soucis de tableaux !

Il y a de nombreuses sources de maux dans Javascript, langage qui devient incontournable sur le Web depuis 5 ans. Mais lorsque les sites traitent de sujets plus complexes ou offres de nouveaux raffinement, ce qui était « une brique parmi d’autres » devient plus sensible.

Commençons par un soucis simple de Javascript : les tableaux.

Allouer un tableau en JS déclenche des mécanismes très différents d’un malloc en C. Allons y ! Sous IE, la logique de traitement est la suivante :

var my_array = new Array();

for (i = 0; i < 100000; i ++)

my_array[i] = i;

1°) Je crée un objet array qui est une table de hashage.

2°) Comme une table de hashage est un objet générique, je lui crée un attribue length (taille) et on le met à 0

3°) La boucle fait, pour chaque valeur de i

• Une conversion de i en string (chaine de caractère, en gros i= « i »)
• Ajoute un clef de hash pour chaque couple « chaine i », i
• Réajuste la valeur de length

OMG. Donc, rien que pour assigner une valeur au tableau, on a fait 3 opérations (dont deux totalement inutile si on a codé un jour en C).

Pour compléter le tableau, les allocations réelles de mémoire ne sont pas continues car les tableaux sont gérés sous la forme de « sparse » array.

C’est avantageux en terme d’usage réel de la RAM car les blocks vides ne sont pas alloués, par contre les allocations ne sont pas contigüe. Du coup, les accès à ces blocks de données ne se font pas à la suite et n’utilise pas certains mécanismes de prédiction des processeurs ou certains caches des OS. De plus les entrées du tableau ne sont pas indexées.

Bon, maintenant, on a tout pour faire une usine à gaz de compétition !

Pour résoudre ce premier point, sous IE 8, le « sparse array » est détecté comme étant dense ou non. En gros il est très peuplé ou non. Pour que l’heuristique de IE8 comprenne que c’est un « dense sparse array », il faut que ce tableau soit d’une taille explicite (en théorie mais un autre blog ne dénote pas de différence de perfs sur ce point) par contre, il faut en initialiser tous les éléments. Le défaut c’est que toute la RAM est allouée et le coté « sparse » disparait.

Sur un gros PC ce n’est pas si dramatique mais sur un téléphone portable, ouch… Du coup, initialiser l’ensemble du tableau n’est pas toujours la bonne option. Un comportement optimal serait de détecter le navigateur et de lui proposer un Javascript optimisé pour le ratio Rapidité, consommation de CPU & RAM, logique de traitement. Une sorte de librairie optimisée de gestion des tableaux, dépendante de la plateforme qui l’exécute.

En termes d’impacts c’est non négligeable !

Quelques très bon liens pour ceux que ca intéresse. Le premier blog a d’ailleurs de très bons papiers d’une manière générale !

http://www.outofwhatbox.com/blog/2009/11/javascript-array-performance-initialize-to-optimize/

http://www.outofwhatbox.com/blog/2009/12/javascript-array-performance-and-why-it-matters/

http://blogs.msdn.com/jscript/archive/2008/03/25/performance-optimization-of-arrays-part-i.aspx

PHP et les performances : plantons le décor

Revenons à nos serveurs ! Dans une infrastructure Magento, ce qui pompe dur au niveau des performances, c’est PHP et de très loin.

Il faut évidemment de la RAM pour accélérer les accès et traiter les données mais les appels PHP coutent très chers. Et c’est bien logique car le Web est coincé dans un incroyable paradoxe.

Les langages interprétés (comme PHP) sont très adaptés à certains traitements mais d’une manière générale, pour tous les traitements répétitifs ou massifs, on les évite.

L’idée c’est que dans la rapidité des langages, l’échelle est très claire :

Les compilés :

Les langages ASM/C et C++ sont compilés et (donc) très rapides. On décrit le code et cela se transforme en Opcode directement interprétables et optimisables par le processeur. Tous les caches deviennent super efficaces (L1/L2/L3 du processeur notamment) et le programme traite les données au fil de l’eau et au fil du temps. Le programme se charge en mémoire, il ne s’arrête que quand on lui demande et peut sommeiller le temps d’attendre son prochain traitement.

Assembleur : niveau processeur directement, très peu voir pas d’interprétation, vitesse maximale.

C : Le code produit par un compilateur C est très proche de l’assembleur et donc extrêmement rapide. Pour autant cela reste un langage relativement évolué, contrairement à l’assembleur on a pas à tout écrire de zéro, des librairies existent, des includes, du code un peu évolué d’une manière générale.

C++ : Un langage C évolué et Objet. On monte encore un peu dans les couches, on fait de l’objet et du fonctionnel, on en est plus à la douce barbarie redoutablement efficace de l’assembleur mais ca reste un code qui, une fois compilé, est redoutablement efficace.

Très peu souples en typage ou en gestion de la mémoire, ces trois langages compilés, pour ne citer qu’eux, sont extrêmement rapides !

La machines virtuelles :

Ce sont des programmes qui crée un environnement permettant d’exécuter d’autres programmes en leur sein. L’intérêt essentiel est de s’affranchir de la couche en dessous, en gros le programme devient portable partout. Si la VM existe pour l’environnement matériel cible, le programme tournera (presque) à l’identique sans rien redévelopper. L’inconvénient, comme toute forme de virtualisation, c’est que la VM consomme de la ressource pour créer cette couche d’abstraction, bilan ces langages ne sont pas toujours des foudres de guerre.

Java et autres JVM

Java est le plus connu des langages tournant dans une machine virtuelle, la JVM. C’est un bon langage, objet, évolué et indépendant du matériel mais il souffre de devoir être compilé tout en étant pas aussi rapide qu’un autre langage compilé.

Les « interprétés » :

Aïe. Perl, PHP et de nombreux copains à eux sont des langages dits « interprétés ». A chaque fois qu’il est lancé, le programme (test.php par exemple) est lu par un interpréteur externe (php par exemple), le fichier est parcouru, compilé à la volée quelque part, mais une fois finit, on repart de zéro. Le fichier programme à interpréter est donc lu à chaque fois et le programme qui le lit, l’interpréteur, est un programme qui est lui chargé à chaque exécution aussi.

PHP :

Un des plus célèbres. Zend au dessus est en fait composé de PHP objet évolué au sein d’un Framework, encore une couche d’abstraction. Donc si l’on compare avec nos précédents amis, Zend c’est le C++, Php le C sauf que tout cela est lu/chargé/parsé/interprété puis exécuté en continu. C’est un peu comme si on avait à se taper la compilation a chaque fois qu’on lance le programme… En fait l’image est très exacte puisque c’est quasiment exactement ce qui se passe. Bilan, les langages interprété c’est pratique, facile à maintenir et programmer, on s’affranchit de tous les aspects un peu rigoureux d’allocation mémoire ou de gestion des taches de bases mais le coût en terme de performances est énorme.

PS : Javascript est un langage de scripting interprété tournant dans une machine virtuelle (navigateur)… Tout pour gagner J

Vers un PHP compilé ?

Comme signalé plus haut, l’interprété c’est consommateur et pas adapté aux traitements récurrents. Maintenant si l’on considère une architecture d’hébergement Web, que se passe-t-il.

Admettons que le site soit en Magento, on a un framework de deuxième niveau, qui repose sur un framework de premier niveau (Zend) qui repose sur un langage interprété objet (PHP5) qui repose sur un interpréteur (Php) qui lui-même est compilé et s’adresse en assembleur au processeur.

Ajoutez un peu de virtualisation là-dessus et avant qu’une requête ne passe à travers tout ce maillage, vous avez perdu une quantité de puissance tout proprement hallucinante !

En soit, aucun reproche au fait d’utiliser PHP ou sa syntaxe, par contre, soyons clairs l’approche est juste complètement aberrante. En fait si on essayait de faire pire, le seul moyen, ca serait de faire tourner l’interpréteur php dans une JVM…

Et oui, ce n’est pas anodin mais bien dramatique. A chaque fichier PHP que vous chargez, l’interpréteur est lancé. A chaque fichier php de chargez, vous provoquez toute la cascade de compilation, d’accès disque, d’exécution. Quand un visiteur passe, il provoque donc des centaines de lancement du programme PHP qui va interpréter autant de fichiers… C’est une boucherie, une hémorragie de puissance pour finalement un problème très bête.

Le problème ce n’est pas Magento, Zend ou les fichiers PHP en soit. Sortons de la barbarie de l’assembleur, vive l’objet et tout et tout, on développe plus vite, on réutilise du code, on capitalise des librairies ! C’est l’avancement logique, l’avenir, donc ca va continuer à se développer. Par contre, pourquoi on ne compile pas tout cela ?

La charge CPU des serveurs serait juste divisée par un facteur 10 à vue de nez… C’est à ce point négligeable ? Plus clairement, sur un serveur, au lieu d’accueillir 20 000 personnes par jours par exemple, on en accueillerait 200 000. Avec le même serveur. L’approximation est un peu grossière mais pas outrancière non plus.

Le Web, qui par essence provoque des milliers de lecture et interprétation de fichier de programme, utilise un système d’interprétation, ce qui est la pire façon de faire, ce qui est le plus consommateur possible. Voici le paradoxe.

Si je me la faisais à la Yann Arthus-Bertrand, je redirais « alors pourquoi toi, homo sapiens sapiens, ne compile tu pas tes langages Web ?». Es-tu conscient des ressources gâchées par cette hérésie et de l’impact, de l’empreinte carbone, de cette approche incompréhensible ? Tu veux vraiment défoncer les puits de soleil ? Tu es un inconscient pathologique, un criminel notoire, un serial-gâcheur ? Ooops, je m’emporte… Yann (dont j’aime beaucoup le travail mais un peu moins la voix monocorde) n’irait pas jusque là !

« Pourquoi ne compile t’on pas ? », bon ok, j’arrête de faire mon YAB…

Je n’ai rien contre les développeurs, qui n’y peuvent pas grand-chose si ce n’est optimiser leur code (ca serait déjà un bon début pour certain ceci étant). Ce qui me froisse par contre, c’est que l’on a pas encore de solutions parfaitement mûres pour corriger ce point.

Des soucis assez complexes de conception sont au rendez-vous pour passer du PHP de l’état interprétable à l’état compilé. Mais ne vous y trompez pas, le Graal est au bout de la route.

Plusieurs initiatives sont en cour de développement par des gens talentueux que je ne peux qu’encourager dans cette voie : Roadsend et PHC (Php compiler mais qui paraît à l’arrêt) semblent être les leaders dans cette voie.

http://www.phpcompiler.org/

http://www.roadsend.com/home/index.php?pageID=compiler

L’autre approche possible serait un cache plus efficace, pas uniquement des opcodes comme APC mais bien des pages rendues, du résultat de l’interprétation PHP. C’est ce vers quoi se dirige Zend Server, c’est une bonne première transition mais le compilateur serait bien LA solution !

En conclusion

Je dirais que PHP et surtout le modèle interprété qui va avec et Javascript et surtout l’implémentation qui en ait faite des les navigateurs autant que dans le code de certaines pages Web, sont deux problèmes.

Ces deux axes de progression nous apporteraient un Web plus rapide, souple et agréable d’utilisation. Le réseau n’est plus réellement une limite, les processeurs sont suffisamment puissants alors deux cas sont possibles :

- Quelques personnes douées arrivent au bout de ces deux problèmes

- Tout le monde se contente de ce qu’on a, on enterre la logique d’optimisation de l’époque atari & amiga, on tue les phoques et la banquise en consommant inutilement des ressources informatiques précieuses. On compense par plus de puissance, plus de ressources consommées, plutôt que de mieux utiliser.

Un classique me direz-vous ?

]]> http://www.wikigento.com/optimisation-lampzendmagento/javascript-php-performances/feed/ 16 http://www.wikigento.com/phpzendmagento/magento-academy-quelques-nouvelles/ http://www.wikigento.com/phpzendmagento/magento-academy-quelques-nouvelles/#comments Mon, 19 Oct 2009 21:02:51 +0000 Philippe Humeau http://www.wikigento.com/?p=1162

Nous y voici, une école exclusivement dédiée à Magento va voir le jour.
Wikigento va répondre à quelques unes de vos questions en exclusivité !

Pourquoi une Magento Academy ?

En premier lieu, la technologie Magento est une indéniable réussite et la demande pour la solution ne cesse d’augmenter.

Les besoins accompagnant une telle expansion sont nombreux et les Web Agencies ont besoin d’un personnel compétent et qualifié pour développer des sites toujours plus nombreux.

Plus de sites à créer sur Magento, parce que la technologie prend des parts de marché mais aussi parce que le E-commerce d’une manière générale se développe. Plus de sites, donc un plus grand besoin  de développeurs.

Il est probable que ce soit une première car très peu de technologies bénéficient d’une école spécifique.

Le besoin d’une école s’explique également par le fait que les développeurs sont de niveaux et d’expériences hétérogènes. Certains maitrisent php4 mais pas encore la POO (programmation Orientée Objet), d’autres déjà Zend et certains enfin ont une expérience significative avec Magento. La chaîne des connaissances nécessaires est très importante et complexe, la qualité des sites qui sortent des mains des développeurs est de fait très différente selon leurs connaissances. La Magento Academy a donc pour vocation de faire un « nivellement par le haut ».

L’Academy sera un Organisme de Formation officiellement agréé ce qui permettra aux entreprises de faire prendre en charge partiellement ou totalement les frais de formations et aux salariés d’exercer leurs D.I.F (droit individuel à la formation).

L’Academy formera aussi les utilisateurs qui administrent le backoffice de Magento et les designers de templates (les intégrateurs graphiques).

Quelle légitimité pour l’Academy et pour ses stagiaires ?

L’Academy est fondée par des experts Magento fortement investis dans la Communauté Francophone de Magento et elle est supportée officiellement par Varien qui en fait son centre officiel et international de formation et de certification.  Le parrain de l’Academy n’est autre que Yoav Kutner, Directeur technique de Varien et co-créateur de Magento.

Les cursus de formation et les méthodes de certifications sont élaborés conjointement par les experts de l’Academy et par Varien. Les certifications seront même signées par Yoav Kutner en sa qualité de Directeur des Certifications !

Grâce à cette méthodologie de travail rigoureuse, les formations enseignées seront ce qui se fait de plus pointu en la matière et l’éditeur lui même fait de l’Academy sont fer de lance en matière de formation et de certification.

Cette première Française est amenée à se développer en Europe et à l’international notamment par le biais du E-learning.

Les niveaux de certifications qui seront obtenus par les stagiaires qui les passeront seront officiellement reconnus par l’éditeur, par l’Academy et plus généralement par la communauté. De facto le monde professionnel apprendra rapidement la valeur de ces niveaux de certifications et pourra aussi en tenir compte pour ses besoins en recrutement ou composition d’équipe.

3 niveaux de certification sont conçus spécifiquement pour le développement : Développeur Magento Certifié (DMC), Spécialiste Magento Certifié (SMC) et le plus haut niveau : Expert Magento Certifié (EMC). (Le niveau d’expert ne pourra être atteint qu’après avoir démontré une expérience significative en plus de réussir la certification, en deux temps donc)

2 autres certifications techniques seront délivrées par l’Academy en dehors des certifications développeurs : Intégrateur &  Chef de projet.

Quel sont les liens entre l’Academy & Varien ?

L’Academy est un partenaire Varien, soutenu par l’éditeur. L’affiliation précise dans le programme de partenariat Varien sera probablement « Industry Partner ».

Il est malgré tout important de préciser que même si l’Academy travaille main dans la main avec Varien (notamment pour les supports et certifications) , Varien n’est en aucun cas actionnaire de l’academy qui est une société indépendante. « Third Party Company’ comme les américains le disent si bien.

La Magento Academy n’est donc ni possédée ni dirigée par Varien, c’est une relation de partenariat fort.

Varien tiens à ce que les partenaires existants ne se sentent pas en danger vis à vis de l’academy, il est donc important de signaler que l’academy est un organisme de formation et en aucun cas une Webagency ou une société d’hébergement ou tout autre métier lié à Magento. L’academy ne sera donc en aucun cas concurrente  des sociétés envoyant leur personnel se former.

Evidemment, tout le monde pourra se faire former sans distinction du moment que les compétences pré requises minimum sont présentes en fonction de la formation demandée. De la même façon les certifications seront les mêmes pour tous, que ce soit en reconnaissance ou au niveau de l’examen, le but de l’academy est de former et/ou de certifier des professionnels pour aider au bon usage et au bon développement de la technologie Magento.

Devra-t-on obligatoirement passer par l’Academy pour être certifié ?

L’Academy est le seul centre officiel de formation à la technologie Magento mais d’autres organismes existent. De même, une personne peut apprendre intégralement par ses propres moyens la technologie et certains développeurs disposent déjà des connaissances nécessaires au passage de la certification.

Dans ces cas, les prétendants à la certification pourront passer l’examen en candidat libre sans être au préalable passés par l’Academy, avec les mêmes chances que tout le monde de réussir les examens.

Quand l’Academy sera-t-elle opérationnelle ?

L’inauguration de l’Academy par son parrain Yoav Kutner aura lieu le 9 novembre 2009 à l’espace Saint Martin lors de Bargento 3. Cette inauguration marquera l’ouverture des premières promotions et les premières certifications auront lieu lors du mois de décembre 2009 ou de Janvier 2010.

L’activité de formation à proprement parler commencera mi novembre.

Quels cours seront dispensés, quels cursus seront disponibles ?

Trois cursus sont prévus pour le moment pour les développeurs : un court, un long et un complet :

• Le cursus développeur court (4/5 jours) est conçu pour les développeurs maitrisant déjà PHP5, la POO et ayant quelques notions en Zend framework. Ce sont des développeurs Web expérimentés qui souhaitent se spécialiser sur Magento. 4 jours de cours seront complétés d’un jour optionnel de spécialisation.
• Le cursus développeur long (~10 j) est destiné à ceux qui veulent explorer les moindres recoins de la technologie. Ils partent avec à peu près les mêmes connaissances que les stagiaires des cursus cours et souhaitent aborder chaque point en profondeur.
• Le cursus complet est fait pour les développeurs « Lamp » qui n’ont pas encore fait le virage PHP Objet. Il comprend une formation PHP5 et POO, une formation aux outils et au framework Zend et une formation Magento. Ce cursus est fait pour ceux qui ont des connaissances en PHP/Mysql et qui souhaitent faire le grand saut vers Magento.

Ceux qui le souhaitent pourront également recevoir un complément de formation relatif à l’amélioration des performances, l’optimisation et l’administration système spécifiquement pour Magento.

Pour les profils qui ne sont pas spécialisés dans le développement, trois cursus sont également prévus :

• Administrateur Magento : Afin d’être totalement autonome avec son nouveau site, une entreprise doit pouvoir maintenir son catalogue, faire le point sur ses ventes ou intervenir sur des points spécifiques. Pour répondre à ces besoins, une formation utilisateur du Backoffice est prévue afin que les utilisateurs finaux puissent cliquer sur les différents boutons de l’interface sans craindre l’armaggédon en permanence
• Intégrateur Magento : Intégrer un template sous Magento demande une maîtrise du système de template. Sans devoir forcément maîtriser l’ensemble de la chaîne de développement, l’intégrateur ne peut se contenter de découpage. Aussi, cette formation permet d’acquérir toutes les connaissances nécessaires aux intégrateurs pour leur permettre les meilleurs intégrations graphiques possibles sur Magento.
• Chef de projet Magento : Comment manager un projet Magento sans connaitre le Framework ? Comment dire à son client si oui ou non ceci ou cela est possible et combien de temps sera alloué à cette tache ? C’est le rôle du chef de projet d’être à la fois conscient des implications techniques et en même temps de se consacrer au fonctionnel qui préoccupe le client. Cette formation s’adresse donc aux chefs de projets Magento.

Une formule « packagée » de formation à l’usage du backoffice sera mis à disposition des Web agency souhaitant intéger un cursus de formation utilisateur à leurs offres de développement.

D’autres questions ?
Posez les directement à contact@magento-academy.com !

Ce coup-ci l’article sera en anglais car c’est une publication d’un white paper rédigé à l’origine par NBS System sur les performances de Magento quand on y couple Zend server. Les tests & benchmarks sont fait entre les versions 1.2, 1.3 et 1.3 avec le flat catalog d’activé puis avec Zend Server et enfin avec Zend server incluant le page cache (version payante).

Ce white paper est en licence Creative commons paternity no commercial use, vous pouvez donc le télécharger, le modifier, le diffuser à votre convenance, sauf pour usage commercial. Celui-ci est uniquement autorisé aux sociétés NBS System, Zend et Varien. (NBS System peut autoriser explicitement l’usage commercial de ce contenu sur demande)

Vous pouvez le télécharger dans sa version PDF intégrale ici.

Magento & Zend Benchmarks

Version 1.2, 1.3 (with & without Flat Catalogs)

1. Foreword

Magento is a PHP/Zend application which intensively uses the CPU. Since version 1.1.6, each new version includes some mechanisms aimed to improve the performances. The goal is to use fewer resources for a given e-shop, which mainly means less CPU, in order to host more users with the same hardware.

One key to achieve better performances is how to optimize PHP pages generation and service. "LAMP" servers are well known and usually run Apache server with mod-php, eventually in fast_cgi mod.

Zend, the PHP Company, made a specific server (Zend Server), which includes a web application stack that (among other things) improves application performances through page caching and opcode reorganization & acceleration.

Apache and Zend Server is an alternative to the usual Apache and mod-php to run Magento, the goal of theses studies & tests is to qualify and estimate the performances added by the use of this software.

Many thanks to Yoav Kutner (Varien's CTO) for providing us with prefilled catalogs for 1.2 and 1.3 version of Magento. Thanks goes as well to Zend labs for providing help in configuration and tweaking of the Zend Server as well as explaining the in depth mechanism of the solution.

2. Methods & tools used

The benchmarks were done using siege (2.66-2), with different numbers of simultaneous threads (5, 10, 20 and 40). Each thread opens a connection to the web server, request a page, and start again as soon as the page is fetched.

Tests were run over 5 minutes each; average pages retrieved was counted for this benchmark.

Two kinds of tests were done: the first one is the simplest; we only load the main page in loop, as fast as possible.

The second test is based on logs produced by a visit, loading all the data the browser collected (including css, js, images ...). As loading a single page would usually load multiple elements, the number displayed is much higher than the number of pages that would be actually seen by visitors.

(18 pages viewed by the user, for 91 items downloaded, a ratio around 5)

All results were obtained on the same hardware and operating system, for testing purposes, no reverse proxy was active during the benchmarks but APC code cache was running. This was a "standard", default environment with no special performance tweaks installed.

Hardware used

Dual Quad-Core AMD Opteron(tm) Processor 2376 (2.3GHz), 8GB Ram, 15K SAS disks. (Dell PE M605)

Software context

Operating system: Linux (2.6.27.10-grsec) on a Debian (lenny)
Web Server: Apache2 (2.2.9-10+lenny2)
PHP (mod-php): mod-php5 (5.2.6.dfsg.1-1+lenny3) / php-apc (3.0.19-2)
PHP (Zend Server): zend-pe (1.0.0-1+b47) / mod-php5-zend-pe (5.2.9+b75)

Repositories

deb http://ftp.fr.debian.org/debian/ lenny main
deb http://security.debian.org/ lenny/updates main
deb http://volatile.debian.org/debian-volatile lenny/volatile main
deb http://repos.zend.com/deb/pe pe non-free

3. Magento Versions benchmarks

Those tests were realized on an 80 000 (later called 80 k) products catalog.

Graphs represent the average number of requests successfully loaded from the server per second during the 5 minutes test.

Loading the homepage

Magento 1.3 is much faster than 1.2 showing the main page. Flat Catalogs do not help much displaying this homepage, and seems to even slow down a little under heavy loads. The performance between 1.2 and 1.3 is doubled for low charges and is still 33% higher under heavy load.

For a standard value, under a "standard" load, we can consider that +40% is a reasonable value when running a 1.3 version instead of a 1.2, at least for the homepage.

Full visit cycle

The graph shows a slightly smaller increase with 1.3 compared to 1.2 and the flat catalog mechanism give an overall benefit which greatly increases the performances.

For the records, we can reasonably choose to keep theses values in mind:

Version 1.2 -> 1.3 : +66%
Version 1.3 -> 1.3+Flat Catalog : +20%

4. Apache + mod-php VS Apache + Zend Server

Zend Server (sometimes refered as ZS later on) comes with several built-in technologies for enhancing application performance:

• Zend Optimizer+ performs byte-code optimization and caching. This speeds up PHP applications by eliminating the process of reading scripts from disk and compiling them. Zend Optimizer+ runs automatically, and installing your application on top of Zend Server (ZS) is all you need to do in order to enjoy its benefits. During the test with ZS, APC Code cache is deactivated as Zend optimizer+ is doing the same job.
• Zend Page Cache allows caching of complete PHP pages. Page Caching greatly improves the performance of web applications while maintaining dynamic capabilities through an elaborate system of caching rules that could be based on request parameters and user session data. Page Caching also has the benefit of not requiring any code changes, and can be set up from the Zend Server UI. Only the "pro" version contains this precise piece of software which definitely makes a difference as we will see in a minute.
• Zend Data Cache is a set of API functions enabling a developer to store and manage data items (PHP strings, arrays and other data) and even output elements in either disk-based cache or shared memory cache. Zend Data Cache allows for precision-guided caching when Page Caching is not an option. The provided API is easy-to-use on existing code, and in many cases a developer can skip existing code sections by simply wrapping them with caching APIs. This precise piece of software would benefit from a little remastering of the code by Varien to really achieve a full support of this functionality. If done, we can imagine selectively flushing the cache when changing some pages on the servers and not destroying the whole Magento cache thus doing a "cold cache start" after a new functionality is put online.

Note: Zend Optimizer+ and Zend Data Cache are available in the free, community version of Zend Server, while Zend Page Cache requires a licensed Zend Server (full comparison of Zend Server and Zend Server Community Edition is located at http://www.zend.com/fr/products/server/editions).

Zend Server Configuration for Magento

In the benchmark, two caching rules have been defined:
The first rule caches the JavaScript files which are dynamically merged into one request by Magento.
This simple rule results in a very substantial improvement to response times.

The second rule caches all web pages accessed by users who have nothing in their shopping carts or history (when the shopping cart is not empty or when the user history is saved, there is no point in page caching). As you can see in the screen capture below, this is accomplished by looking at $_SESSION variables and by splitting according to $_SERVER['REQUEST_URI'] in addition to the QUERY_STRING.

Finally, Zend Optimizer+ has been enabled for optimizing and caching the PHP byte-code.

As you can see, Zend Page Cache seems a very powerful feature. It needs fine tuning and better configuration, but let's see results :

Homepage / 80 000 products catalog

Load on main page doesn't prove very constructive, although, on heavy load (40 concurrent requests), Zend Server (with or without page cage) is slightly better than basic mod-php, but almost no real improvements on this test. A 5% or less win is not to be taken seriously as it is the error margin of the tests.

Full visit / 80k products

Full visit graphic speaks for itself, whatever the load, Zend Server with Page Cache and Flat Catalog make a big difference.

Comparing a 1.3 with flat catalog with a the same configuration but with a Zend Community installed instead of just APC, our server yield up to 15% more performances, just using a free edition of ZS.

If we use a full Zend server (the licensed one including the page cache) on this 1.3 flat catalog, our server goes up to 30% more performances!

Mod PHP + APC -> ZS: +15%
Mod PHP + APC -> ZS licensed edition: +30%

5. Response time

Homepage / 80k products

This graph show response time on the homepage measured during a load. No match on this test, under a good load, ZS, community or licensed edition, gives up a 35% boost in the load time, good to take.

Full visit / 80k products

Page Cache provides a better response time over a full visit of the site, even under very heavy load. As the difference remains thin, I would conclude it to be identical in that condition. However, the benefits of the page cache under a standard load remains a must have. Once again, a 35% win is to be considered as a reference value under a good load whether you are using a community or licensed version.

Under medium or light load, the page cache is giving a lot more power than the community edition can do. This strange result is probably mainly due to the page cache mechanism which prove to be not that efficient under heavy load because the system is using its resource in a different way.
We didn't had time to check if it was a False cache sharing effect on L2 or L3 processor cache or a Linux or ZS issue but the test has been runned several times yielding the same results.

So keep in mind that the benefits of the ZS Page cache mechanism is going to be less and less active as the server load gets high. Under a usual load, a reasonable load lets say, the Page Cache algorithm gives a nice boost to the loading time, driving it down for ~40%.

6. Additional technical details about the tests

Sample data

All tests were run with generated sample data (provided by Varien)

Description of the tests

Main page test

Each concurrent thread loads the main page, without storing the cookies to simulate simultaneous users.

Full visit test

We have a list requests based on a visit done with a real browser. Each concurrent thread loads each item one after another as fast as possible, and restarts after deleting all its cookies. This simulates simultaneous users, except that simultaneous.

List of requested pages for the 80k database (with POST information when it applies):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91

<span style="font-size: xx-small;">http://test80k/
http://test80k/skin/frontend/default/default/favicon.ico</span>
<span style="font-size: xx-small;">http://test80k/js/index.php?c=auto&amp;f=,prototype/prototype.js,prototype/validation.js,scriptaculous/builder.js,scriptaculous/effects.js,scriptaculous/dragdrop.js,scriptaculous/controls.js,scriptaculous/slider.js,varien/js.js,varien/form.js,varien/menu.js,mage/translate.js,mage/cookies.js
http://test80k/skin/frontend/default/default/css/reset.css
http://test80k/skin/frontend/default/default/css/menu.css
http://test80k/skin/frontend/default/default/css/print.css
http://test80k/skin/frontend/default/default/css/clears.css
http://test80k/skin/frontend/default/default/css/boxes.css
http://test80k/skin/frontend/default/default/images/body_bg.gif
http://test80k/skin/frontend/default/default/images/logo.gif
http://test80k/skin/frontend/default/default/images/btn_mini_search.gif
http://test80k/skin/frontend/default/default/images/mini_search_bg.gif
http://test80k/skin/frontend/default/default/images/nav_bg.jpg
http://test80k/skin/frontend/default/default/images/nav_divider.gif
http://test80k/skin/frontend/default/default/images/main_container_bg.gif
http://test80k/skin/frontend/default/default/images/shop_access_pipe.gif
http://test80k/skin/frontend/default/default/images/base_mini_head_bg.gif
http://test80k/skin/frontend/default/default/images/media/col_left_callout.jpg
http://test80k/skin/frontend/default/default/images/header_top_container_bg.jpg
http://test80k/skin/frontend/default/default/images/icon_table.gif
http://test80k/skin/frontend/default/default/images/icon_newspaper.gif
http://test80k/skin/frontend/default/default/images/icon_tag_green.gif
http://test80k/skin/frontend/default/default/images/icon_basket.gif
http://test80k/skin/frontend/default/default/images/media/col_right_callout.jpg
http://test80k/skin/frontend/default/default/images/footer_info_separator.gif
http://test80k/skin/frontend/default/default/images/main_bg.gif
http://test80k/category-736
http://test80k/skin/frontend/default/default/images/layered_nav_head_bg.gif
http://test80k/skin/frontend/default/default/images/layered_nav_narrowed_category_heading.gif
http://test80k/skin/frontend/default/default/images/narrow_by_set.gif
http://test80k/skin/frontend/default/default/images/narrow_by_dd_bg.gif
http://test80k/skin/frontend/default/default/images/pager_arrow_right.gif
http://test80k/skin/frontend/default/default/images/sort_asc_arrow.gif
http://test80k/media/catalog/product/cache/1small_image/135x135/5e06319eda06f020e43594a9c230972d/images/catalog/product/placeholder/small_image.jpg
http://test80k/skin/frontend/default/default/images/pager_bg.gif
http://test80k/category-736?attribute_864=306
http://test80k/skin/frontend/default/default/images/list_remove_btn.gif
http://test80k/skin/frontend/default/default/images/narrow_category_bg.gif
http://test80k/skin/frontend/default/default/images/narrow_by_li_by.gif
http://test80k/category-736?attribute_864=306&amp;price=3%2C100
http://test80k/category-736?attribute_864=306&amp;price=3%2C100&amp;p=2
http://test80k/skin/frontend/default/default/images/pager_arrow_left.gif
http://test80k/category-736?attribute_864=306&amp;price=3%2C100&amp;p=3
http://test80k/category-736/gtx14049.html
http://test80k/js/index.php?c=auto&amp;f=,prototype/prototype.js,prototype/validation.js,scriptaculous/builder.js,scriptaculous/effects.js,scriptaculous/dragdrop.js,scriptaculous/controls.js,scriptaculous/slider.js,varien/js.js,varien/form.js,varien/menu.js,mage/translate.js,mage/cookies.js,varien/product.js,calendar/calendar.js,calendar/lang/calendar-en.js,calendar/calendar-setup.js
http://test80k/js/calendar/calendar-win2k-1.css
http://test80k/media/catalog/product/cache/1/image/265x/5e06319eda06f020e43594a9c230972d/images/catalog/product/placeholder/image.jpg
http://test80k/skin/frontend/default/default/images/product_essential_bg.gif
http://test80k/skin/frontend/default/default/images/product_collateral_bg.gif
http://test80k/skin/frontend/default/default/images/dotted_divider.gif
http://test80k/skin/frontend/default/default/images/icon_tag_add.gif
http://test80k/checkout/cart/add/uenc/aHR0cDovL3Rlc3RtMTIudGVzdC5uYnMtc3lzdGVtLmNvbS9jYXRlZ29yeS03MzYvZ3R4MTQwNDkuaHRtbD9fX19TSUQ9VQ,,/product/67952/ POST product=67952&amp;related_product=&amp;qty=
http://test80k/checkout/cart/
http://test80k/js/index.php?c=auto&amp;f=,prototype/prototype.js,prototype/validation.js,scriptaculous/builder.js,scriptaculous/effects.js,scriptaculous/dragdrop.js,scriptaculous/controls.js,scriptaculous/slider.js,varien/js.js,varien/form.js,varien/menu.js,mage/translate.js,mage/cookies.js,varien/weee.js
http://test80k/skin/frontend/default/default/images/btn_proceed_to_checkout.gif
http://test80k/skin/frontend/default/default/images/btn_trash.gif
http://test80k/media/catalog/product/cache/1/thumbnail/75x/5e06319eda06f020e43594a9c230972d/images/catalog/product/placeholder/thumbnail.jpg
http://test80k/skin/frontend/default/default/images/success_msg_icon.gif
http://test80k/skin/frontend/default/default/images/icon_asterick.gif
http://test80k/skin/frontend/default/default/images/icon_lorry.gif
http://test80k/skin/frontend/default/default/images/data_table_th_bg.gif
http://test80k/skin/frontend/default/default/images/base_mini_actions_bg.gif
http://test80k/category-736/gtx14049.html
http://test80k/media/catalog/product/cache/1/thumbnail/50x50/5e06319eda06f020e43594a9c230972d/images/catalog/product/placeholder/thumbnail.jpg
http://test80k/category-1497
http://test80k/media/catalog/product/cache/1/small_image/135x135/5e06319eda06f020e43594a9c230972d/images/catalog/product/placeholder/small_image.jpg
http://test80k/category-1497?attribute_864=305
http://test80k/category-1497/npt25-a.html
http://test80k/media/catalog/product/cache/1/image/265x/5e06319eda06f020e43594a9c230972d/images/catalog/product/placeholder/image.jpg
http://test80k/checkout/cart/add/uenc/aHR0cDovL3Rlc3RtMTIudGVzdC5uYnMtc3lzdGVtLmNvbS9jYXRlZ29yeS0xNDk3L25wdDI1LWEuaHRtbD9fX19TSUQ9VQ,,/product/25870/ POST product=25870&amp;related_product=&amp;qty=
http://test80k/checkout/cart/
http://test80k/media/catalog/product/cache/1/thumbnail/75x/5e06319eda06f020e43594a9c230972d/images/catalog/product/placeholder/thumbnail.jpg
http://test80k/category-3
http://test80k/media/catalog/product/cache/1/thumbnail/50x50/5e06319eda06f020e43594a9c230972d/images/catalog/product/placeholder/thumbnail.jpg
http://test80k/category-3?price=4%2C1000
http://test80k/checkout/cart/add/uenc/aHR0cDovL3Rlc3RtMTIudGVzdC5uYnMtc3lzdGVtLmNvbS9jYXRlZ29yeS0zP3ByaWNlPTQlMkMxMDAwJmNhdD0zNyZfX19TSUQ9VQ,,/product/4642/
http://test80k/checkout/cart/
http://test80k/checkout/onepage/
http://test80k/js/varien/accordion.js
http://test80k/skin/frontend/default/default/js/opcheckout.js
http://test80k/skin/frontend/default/default/images/opc_off_head_bg.gif
http://test80k/skin/frontend/default/default/images/opc-ajax-loader.gif
http://test80k/skin/frontend/default/default/images/btn_window_close.gif
http://test80k/skin/frontend/default/default/images/cvv.gif
http://test80k/skin/frontend/default/default/images/multi_address_box_bg.gif
http://test80k/skin/frontend/default/default/images/btn_place_order.gif
http://test80k/catalogsearch/ajax/suggest/ POST q=45
http://test80k/catalogsearch/ajax/suggest/ POST q=456
http://test80k/catalogsearch/result/?q=456&amp;x=17&amp;y=8
http://test80k/media/catalog/product/cache/1/small_image/135x135/5e06319eda06f020e43594a9c230972d/images/catalog/product/placeholder/small_image.jpg
http://test80k/media/catalog/product/cache/1/thumbnail/50x50/5e06319eda06f020e43594a9c230972d/images/catalog/product/placeholder/thumbnail.jpg</span>

7. Things to test in the next benchmark campaign

Mage Compiler

When running all those tests, 1.3.1.1 version including the Mage optimizer was about to be released and an immediate 1.3.1.2 version followed and we didn't had time to include some tests around this precise point. Let's just consider the fact that this mechanism is mainly made to lower I/O jobs by "compiling" the libraries files all in one or two includes only. If your servers were already using mainly their RAM to work, the performances increase will not be that valuable. But if your servers where low on RAM or using mainly their disks, you should feel confident with using this option which can do great good to your performances!

Nginx

We didn't had the required time to consolidate the results involving Nginx + PHP tests. This solution ranked almost every time between Magento 1.3 + FC and Magento 1.3 + Zend server (without Page cache). So this combination yield average performances, not as sharp as a Magento 1.3 + Zend server or any more advanced combination.

More "customed" visits

We have used a scenario involving each time a research in the search bar of the website and some "standard" behaviors. A more precise test can be run replaying some real traffic pumped up from apache log on a real site, the customer's behaviors being more realistic even if our scenario was as logical as possible.

8. Conclusion

First, let me say that no electrons were armed or injured during these benchmarks. Perhaps one or two CTO were put under constraint and continuous coffee perfusions but all of this was intend for the greater good of E-commerce!

If you wish a more professional conclusion, let's say that using ZS community edition will only do you good and really can replace APC.

If using the licensed version, the Page cache is very efficient (under reasonable load of the servers) and can help using ~25% less machines to achieve similar hosting capacities. If your servers are billed in a "managed hosting" way, having one or two less servers billed per month can make a good difference in the budget.

About Zend Server : this software has many other great functionalities and this paper is only consider the "performances" issues, just pay a visit to Zend Website for a far more complete overview of the product.

Last but not least, creating a server with all optimizations and best practices, based on an a dual AMD 2376 with 8 Go of RAM and using ZS and page cache, you can try to reach up to ~40 000 unique visitors a day corresponding to ~2 500 Magento simultaneous session at maximum load. (if database is separated on a different server and you activate a reverse proxy like Squid or Varnish above your front web servers)
This estimation is deeply linked to the website complexity and user standard behavior but these figures are given for a "standard" site and use, you can usually also expect a ~2 seconds loading time on the homepage.

If we had to sum up a quick dirty, average table of the performances, without any details, we would give that:

© June 2009, NBS Team,

René Amirkhanian, Adrien Urban, Philippe Humeau,
you can visit us here: www.nbs-system.com
and reach us at: contact@nbs-system.com for any comments or corrections (and yes, we do hosting )

9. Creative Commons

This document is released under the creative common license "Attribution-Noncommercial-Share Alike 3.0". Only three companies (NBS System, Zend and Varien) are allowed to use it for commercial purposes.

Cet article est le premier que je consacre aux modules, c’est un vaste sujet sur lequel il y a beaucoup à dire.
Dans ce premier article je vais introduire les modules, leur capacités et leurs limites.

1. Introduction

Au delà de Magento les plateformes e-commerce ont toutes été confronté à un problème, peut importe le nombre de fonctionnalités proposées, il est impossible de satisfaire les besoins spécifiques de chaque site e-commerce avec une plateforme générique.

L’intégrateur doit alors modifier la plateforme et l’adapter aux besoins. Ces modifications peuvent être faîtes de différentes manières selon les plateformes. On distingue 2 types de plateformes celles qui sont modulaires et celles qui ne le sont pas.

Quand on parle de plateforme modulaire on sous-entend surtout un code qui est modulable, en effet toute solution e-commerce possède son code qui est le moteur original de la plateforme, dans Magento on l’appelle le core.
Personnaliser la plateforme implique donc de pouvoir modifier le moteur afin qu’il réponde a nos besoins. Ce travail est plus ou moins facilité par la flexibilité que va vous apporter la plateforme choisie et est donc l’un des critères dans le choix d’une solution e-commerce.

2. Les ancêtres

Magento s’étant positionné comme un concurrent direct à OsCommerce je m’autorise un encart au sujet des modules sur cette plateforme.

Les gens qui ont travaillé avec OsCommerce l’on connu : (voix venu d’outre-tombe)l’enfer des contributions.
Plus sérieusement, OsCommerce est l’exemple parfait d’une solution qui n’est presque pas modulaire, je dis presque car elle l’est tout de même concernant les modules de paiement et de livraison.
Installer une extension sur OsCommerce était long et fastidieux. A la longue on se retrouvait avec un code exotique qui n’avait plus rien à voir avec le code d’origine.

Pire, c’est un cercle vicieux car plus vous modifiez les sources plus il est difficile d’y apporter de nouvelles modifications. Plus on modifie et plus la probabilité de bug est grande, et surtout en cas de problème grave il y a un risque de se retrouver dans une impasse technique : impossible de diagnostiquer un problème car le code est devenu un véritable capharnaüm.

3. Ce qu’apporte Magento

On le sait Magento est basé sur une architecture Zend framework, autrement dit Magento respecte un standard créé par Zend qui n’est autre que le créateur de PHP4 et 5.

Concrètement : Magento est modulaire.

Encore plus concret : le Core est lui même constitué de modules, si je devais donner un exemple ce serait le module de base de Magento qui s’apelle « Core » que vous trouverez dans le répertoire /app/code/core/Mage/Core

Cette architecture à base de modules implique qu’on pourra en rajouter d’autres. L’avantage des modules étant qu’ils se greffent automatiquement aux autres modules sans que vous ayez besoin de toucher au Core.

Les principaux avantages sont de rester compatibles avec des mises à jours ultérieure et d’éviter au Core de se transformer en une grosse tumeur à la croissance incontrôlable et ingérable sur la durée.

Mais Magento apporte également une séparation Code/design qui permet de séparer les traitements de l’affichage, avec d’autres avantages comme la gestion multi-design.

En plus Magento fourni un outil qui facilite le déploiement des modules au travers Magento Connect. Cette plateforme permet non seulement de référencer tous les modules existants mais également d’automatiser le processus d’installation et de mise à jour des modules.

4. Ce que peuvent faire les modules

Voici une liste non-exhaustive de ce peuvent faire les modules
- Apporter de nouvelles fonctionnalités
- Modifier des fonctionnalités existantes
- Ajouter un template et/ou une skin
- Enrichir l’API (WebService)
- Intercepter des évènements (enregistrement d’une commande, création d’un produit, etc …)

5. Et donc ?
En fait Magento nous offres une boite à outils formidable, les développeurs avec qui j’ai eu l’occasion de discuter sont unanime sur ce point : pour du développement Magento est un modèle du genre, efficace et fonctionnel et c’est ce qu’on lui demande.

En revanche exit les bidouilles, avec Magento on ne développe plus de l’approximatif car une connaissance sérieuse de framework est nécessaire, elle peut s’acquérir à l’usage mais pour ceux qui se lance compter 2 mois de grosses galères si vous n’avez jamais mis les pieds dans Magento et/ou Zend.

Ajoutez à ça que le code exploite pleinement la POO (programmation orientée objet) fournie par PHP il est donc important de maîtriser cette forme de programmation puisque Magento use et abuse des classe, héritage, surcharge, il ne manque que le polymorphisme qui n’existe pas en PHP5.

J’ai pour habitude de dire que Magento n’est réellement accessible qu’aux ingénieurs en développement, c’est un cliché bien sûr car l’expérience et la débrouillardise/motivation peut remplacer le diplôme, mais l’idée est là.

Pour l’anecdote j’avais un jour discuté avec le gérant d’un site e-commerce qui m’avait confié que ses devs, à l’aise dans OsCommerce, se trouvèrent complètement à la rue avec Magento et il du faire appel à un prestataire spécialisé, pour autant il ne regrettait pas son choix car Magento est un excellent outil une fois en place.

6. Ensuite …
J’écrirai d’autres articles dans lesquels je rentrerai plus en détail sur la conception des modules, peut être plus sous forme de tutoriaux avec des exemples de codes (merci Philippe pour l’ajout de la gestion du code dans le blog), en tout cas je compte spécialiser chaque article autour d’un exemple concret de réalisation.

Celle-ci a été annoncée par Varien comme salvatrice pour les performances de notre outil e-commerce préféré (le site annonce un bénéfice de 40% sur le temps de chargement des pages en front office et sur l’utilisation de la mémoire).

Concrètement, que se cache-t-il vraiment derrière cette option « magique » et quel impact aura-t-elle sur les prochains projets construits sur la base de cette version?

Avant toute chose, rappelons que Magento repose actuellement sur un modèle de données de type « EAV » (Entity-Attribute-Value). Ce qu’il faut comprendre c’est qu’un objet « Produit » dans Magento n’est pas stocké dans une seule table mais éclaté dans un ensemble de tables en fonction des attributs de notre produit. Cette complexification du modèle de données se justifie en grande partie par la souplesse que propose Magento dans le paramétrage de nouvelles caractéristiques pour un produit.

Mais cette souplesse a donc un coût puisqu’il multiplie de manière importante le nombre de requêtes effectués en base pour un seul produit. On touche donc très vite aux limites de ce modèle dès lors qu’on travaille avec un catalogue important (plus d’une dizaine de millier de références). Varien a donc annoncé en début d’année qu’ils proposeraient une simplification de ce modèle sous forme d’une option librement activable depuis le back office pour permettre de basculer vers un modèle de données « à plat ».

En regardant de plus près, cette option est un peu plus subtile que ce à quoi on pouvait s’attendre: une fois le mode ‘flat catalog’ activé dans l’administration, on se retrouve finalement avec deux catalogues: un pour le backoffice, et un pour le front:

• celui du backoffice reste le catalogue EAV tel qu’il existe dans la 1.2
• le front utilise des nouvelles tables catalog_category_flat et catalog_product_flat
• il y a une synchronisation type maître-esclave entre le catalogue backoffice et celui du front

Finalement, le « flat catalog » du front est en réalité une sorte de table de cache pour le vrai catalogue qui reste en EAV.

Les avantages de ce fonctionnement:

• la migration est bien plus simple puisqu’en réalité le format de la base n’a pas vraiment changé (les tables _flat sont générées à la demande depuis le backoffice)
• on peut imaginer facilement avoir une base de données front avec les tables _flat côté frontoffice, séparées physiquement de la base de backoffice, avec le moteur Federated de MySQL qui permet de présenter plusieurs bases de données comme en étant une seule aux applications. De ce fait, la charge sur le front n’impacte pas le back et inversement

Les inconvénients:

• avec des volumétries très élevées, (certains) écrans du backoffice vont être très lents puisqu’ils continueront à utiliser le système EAV
• les imports devront continuer à se faire dans les tables EAV, d’où une lenteur au moment de l’import (à nuancer: si les données importées ne sont pas destinées à être utilisées dans le backoffice, il est peut être possible de les importer directement dans les tables _flat du front)

Nos premiers tests sur la base de ce nouveau modèle et d’un catalogue de plus d’un million de produits devraient désormais nous fixer assez rapidement sur la pertinence de cette fonctionnalité…

A suivre donc!

Cette petite bête s’appelle Web Service ou API et derrière ce nom d’insecte se cache l’une des fonctionnalités les plus importantes de Magento dans le cadre de l’intégration d’une boutique Magento à un système d’information.

C’est quoi un Web Service ?

Si je devais illustrer ce qu’est un Web Service je dirais que c’est à Magento ce que le langage des signes est aux sourds. C’est un moyen de communication.

Un moyen de communication mais pour qui ?

Pour tous les logiciels qui auraient besoin de dialoguer avec Magento. Votre logiciel de gestion comptable, de gestion commerciale ou autre.

Pour quoi faire ?

A travers le Web Service un logiciel tiers pourra par exemple récupérer la liste des commandes, ajouter des produits, ajouter des catégories, …
Je parlais au début d’intégration dans le système d’information, vous devez commencer à voir le potentiel de l’API, un logiciel de comptabilité pourra récupérer les commandes et mettre à jour automatiquement votre compta, votre logiciel de suivit des stocks ou de production pourra prendre en compte les volumes de produits commandé et les mettre à jour.

Oui mais ça on le faisait déjà avant

Probablement tant ce genre de fonctionnalité est importante, toutefois les plateformes e-commerce gratuite disposent rarement d’un Web Service natif en fait je n’en connais pas à part Magento. Donc si vous l’aviez fait auparavant vous aviez probablement du faire faire un développement spécifique (mise en place d’un Web Service, envoi de fichier, ou autre).

Donc

L’intérêt premier de ce Web Service est :

• Sa disponibilité assure d’une part l’homogénéité d’une plateforme Magento à l’autre (le Web Service est le même sur toutes les boutiques Magento)
• Accélère l’intégration puisqu’il n’y plus besoin de le développer (réduisant les coûts de développement)
• L’aspect Web Service assure que la communication sera bien assurée sans devoir personnaliser la sécurité du site puis qu’un appel standard au Web Service se fait avec le protocole http sur le port 80, il est possible si besoin de passer par du https si on veut sécuriser les données transitant sur le web.
• Et enfin on bénéficie de la sécurité intégrée à Magento et du framework Zend.

Comment ça marche ?

Sans rentrer dans les détails un Web Service communique avec un langage standardisé que n’importe quel programme est capable de générer : des flux XML.
Magento supporte 2 protocoles de Web Service nativement, vous pouvez utiliser au choix SOAP ou XML-RPC, pour ceux qui ne savent pas les 2 sont du XML, mais la manière de formater les 2 n’est pas la même, l’utilisation de l’un ou l’autre dépendra principalement de l’environnement technique.
Sachez cependant qu’un Web Service ne sait pas parler, il ne sait que répondre il doit donc être sollicité à chaque fois qu’on a besoin d’une information.
Exemple :  Le Web Service ne pourra pas de lui-même envoyer les commandes à votre comptabilité, c’est la comptabilité qui devra solliciter le Web Service et lui demander la liste des commandes.
Et la sécurité ?

Je n’ai pas personnellement fait de test de sécurité mais je pense que cette partie est robuste en voiçi les raisons :

Le Web Service n’expose que 8 méthodes publiquement et aucune de ses méthodes ne permet d’accéder aux données :

• startSession()
• login(apiUser, apiKey)
• endSession(sessionId)
• call(sessionId, resourcePath,array arguments)
• multiCall(sessionId, array calls,array options)
• resources(sessionId)
• globalFaults(sessionId)
• resourceFaults(sessionId, resourceName)

Pour accéder aux données il faut utiliser call ou multiCall, Magento vérifie alors que l’utilisateur a le droit d’utiliser la méthode appelée grâce au système ACL de Zend.
A partir de là j’imagine que ces méthodes publique ont été correctement protégé et qu’en conséquence la sécurité du site n’est pas compromise.
Toutefois il y a un point qui me chiffonne c’est que les requêtes http et les flux XML sont tout de même facile à intercepter pour qui le veut, or un appel à la méthode login envoie le login et mot de passe en clair, c’est pourquoi je pense qu’il faut privilégier les appels en https.

Et les performances ?

Soyons franc la communication passant par Web Service c’est lent et ça consomme, par exemple voici le flux XML envoyé pour l’authentification, on envoie que 3 paramètres :
<?xml version= »1.0″?>
<methodCall>
<methodName>login</methodName>
<params>
<param>
<value>
<string>Fabrice</string>
</value>
</param>
<param>
<value>
<string>123456</string>
</value>
</param>
</params>
</methodCall>
Pour 20 caractères pertinents on en envoie 10x plus à côté, et encore ici c’est de l’XML-RPC, SOAP est encore plus consommateur. De plus les temps de réponses sont longs (on compte en secondes) entre le moment ou on envoie la requête et le moment ou on reçoit la réponse. Et je ne parle pas de la consommation de ressources serveurs liée à l’exécution des requêtes en elle-même, mais à mon avis récupérer la liste des produits d’une boutique en ayant 5000+ pendant les soldes est selon moi une mauvaise idée (qui tente l’expérience ?). Ces aspects ne gâchent en rien l’utilité du Web Service mais il important d’en connaître les défauts si on veut l’exploiter de manière optimale.

Concrètement comment je peux faire appel à l’API ?

La première chose à connaitre est l’adresse du Web Service, elle dépend surtout du type de Web Service que vous souhaitez utiliser :
SOAP : http://www.monsite.com/api/?wsdl
XML-RPC : http://www.monsite.com/api/xmlrpc/

Ensuite cela dépend du langage que vous allez utiliser, commençons par PHP car c’est facile :

1. $client = new SoapClient(‘http://www.monsite.com/api/?wsdl’);
2. // Vous pouvez aussi utiliser
3. // http://www.monsite.com/api/soap/?wsdl
4. // Si on a besoin de s’authentifier,
5. // on récupère le jeton de session
6. $session = $client->login(‘apiUser’, ‘apiKey’);
7. $result = $client->call($session, ‘module.methode’);
8. $result = $client->call($session, ‘module.methode’, ‘arg1′);
9. $result = $client->call($session, ‘module.methode’, array(‘arg1′, ‘arg2′, ‘arg3′));
10. // Si on a fini on termine la session
11. $client->endSession($session);

Faisons un peu de .Net

En .Net c’est un peu plus compliqué, bien que le framework .Net supporte le SOAP, il y a visiblement un problème de norme entre SOAP Magento et SOAP .Net ce qui rend cette librairie inutilisable.

Il va donc falloir passer par XML-RPC. Malheureusement ce type n’est pas supporté nativement par .Net, toutefois il existe une très bonne librairie gratuite créé par Cook Computing.

Pour l’utiliser il va falloir créer l’interface des méthodes publique du WebService Magento, voici la mienne :

using System;
using System.Text;
using CookComputing.XmlRpc;
public interface XmlRpcInterfaces : IXmlRpcProxy
{
  [XmlRpcMethod("login")]
  string login(string apiUser, string apiKey);

  [XmlRpcMethod("endSession")]
  bool endSession(string sessionID);

  [XmlRpcMethod("call")]
  XmlRpcStruct[] call(string sessionID, string resourcePath, object[] data);

  [XmlRpcBegin]
  IAsyncResult Begincall(string sessionID, string resourcePath, object[] data);

  [XmlRpcBegin]
  IAsyncResult Begincall(string sessionID, string resourcePath, object[] data, AsyncCallback acb);

  [XmlRpcBegin]
  IAsyncResult Begincall(string sessionID, string resourcePath, object[] data, AsyncCallback acb, object state);

  [XmlRpcEnd]
  XmlRpcStruct[] Endcall(IAsyncResult iasr);
}

Notez que je n’ai implémenté que 3 des 8 méthodes publiques et que j’ai implémenté la méthode call pour pouvoir faire des appels asynchrone (avec du polymorphisme en prime).

Pour l’utiliser c’est relativement simple, si je devais reprendre l’exemple PHP ça nous donnerai en C# :

1. XmlRpcInterfaces proxy = XmlRpcProxyGen.Create<XmlRpcInterfaces>();
2. XmlRpcStruct[] result;
3. proxy.Url = @ »http://www.monsite.com/api/xmlrpc/ »;
4. string session = proxy.login(« apiUser », « apiKey »);
5. result = proxy.call(session, « module.methode », new object[] { });
6. result = proxy.call(session, « module.methode », new object[] { « arg1″ });
7. result = proxy.call(session, « module.methode », new object[] { « arg1″, « arg2″, « arg3″ });
8. proxy.endSession(session);

Les appels asynchrone

Ce qu’il y a de bien avec des langages comme .Net ou Java c’est la possibilité de faire des appels Asynchrone, plutôt que d’attendre la réponse du serveur on envoie la requête et on déclenche un évènement dès que l’on réceptionne la réponse.

C’est possible à faire avec le WebService de Magento à 2 conditions :
Tout d’abord il faut implémenter la gestion de l’appel Asynchrone (déjà fait dans mon exemple pour call) de la méthode.
Ensuite il faut absolument que le serveur Apache soit configuré de manière à pouvoir garder en vie la session, sans ça vous avez toutes les chances que la session expire entre 2 requêtes ou même entre la requête et la réponse.

Dans la plupart des cas les appels asynchrone ne sont pas possible car Apache n’est pas configuré pour cela par défaut, un moyen de contourner cela est de faire des appels synchrone dans des threads séparés.

Etendre le Web Service

Utiliser le Web Service est ce dont vous avez besoin mais les traitements proposés ne vous conviennent pas ?
Qu’a cela ne tienne, il est parfaitement possible de créer de nouvelles méthodes dans l’API en les implémentant dans un module Magento. Je ne ferai pas de cours sur ce point maintenant car j’ai l’intention d’écrire un article dédié aux modules ultérieurement. Sachez juste que c’est facile à faire.

Conclusion

Le Web Service c’est le bien.

Son utilisation est un vrai bonheur pour relier des applications à Magento avec les exemples que j’ai donné vous devriez pouvoir l’utiliser vous même assez facilement. Pour les marchands ou futur marchands vous connaissez désormais un des potentiels de Magento.