Javascript et PHP sont-ils des sources de ralentissements ?

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 ?

écrit par Philippe Humeau \\ tags: compilation php, interprétation php, langage interprété, performance Javascript, performance magento, performance php, performance zend

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 !

écrit par Philippe Humeau \\ tags: académie magento, Magento Academy

Bonjour à toutes et à tous,

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.

Lire la suite »

écrit par Philippe Humeau \\ tags: Magento and Zend server performances benchmark, Magento Zend server, Zend and Magento, Zend page cache, Zend server benchmark, Zend server performances

La modularité est probablement l’une des fonctionnalités apportées par Magento la plus intéressante, à la fois pour le marchand et pour l’intégrateur.

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.
Lire la suite »

écrit par Fabrice Beck \\ tags: code, connect, contribution, developpement, magento, module, php

La dernière version de Magento est sortie cette nuit et avec elle arrive l’option tant attendue : le Flat Catalog!

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!

écrit par Frederic de Gombert \\ tags: eav, flat-catalog, modele de données, optimisation

Le but de cet article est de vous faire découvrir un aspect très important de Magento et pourtant  peu sexy car il s’adresse plus aux développeurs qu’aux marchands.

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.

Lire la suite »

écrit par Fabrice Beck \\ tags: .net, api, magento, php, service, soap, web, webservice, xml, xml-rpc