Conférence sur "Les nouvelles technologies de l'ecommerce" à l'EPITECH

Les sociétés Stockho SI et Baobaz donneront une conférence sur "Les nouvelles technologies de l'e-commerce".

 

Lors de cette conférence, et en partenariat avec SUN Microsystems, différents résultats issus du R&D seront présentés et analysés. Les thèmes principaux abordés seront la technologie Magento, le cloud computing appliqué à l'ecommerce et l'optimisation des sites Magento.

 

Un cocktail sera organisé en fin de présentation pour permettre à tous d'échanger !

 

La conférence aura lieu le mercredi 22 mars 2010 à partir de 18:00 dans les locaux de l'EPITECH :

EPITECH - Amphi P04

14-16, rue voltaire

94270 Le Kremlin Bicêtre

 

Si vous voulez vous inscrire veuillez envoyer un mail à l'adresse conference [at] stockho.com.

 

Problèmes d'affichage dans le back-office Magento

Plusieurs problèmes sont connus sur la version 1.3.2.4 de Magento.

Le premier de ces bugs est dû au compilateur (intégré à Magento) en version beta activé par défaut. Ce bug est visible dans "System > Magentoc Connect > Magento Connect Manager" ou "System > Magento Connect > Package Extensions"

Fatal error: main() [function.require]: Failed opening required '/data/www/html/magedemo/includes/downloader/pearlib/php/PEAR.php' (include_path="/data/www/html/magedemo/includes/downloader/pearlib/php : /data/www/html/magedemo/includes/src:.:/usr/local/lib/php") in /data/www/html/magedemo/includes/src/Varien/Pear.php on line 265

Pour résoudre ce problème, il suffit de désactiver le Compilateur dans Système > Outils > Compilation.

Le second bug rencontré est un bug d'affichage du javascript aussi bien dans le back-office que sur le front-office. Dans certains cas, tout le JavaScript (menu déroulant, ...) ne s'affiche pas.

Pour résoudre ce problème il faut modifier le fichier app/code/core/Mage/Page/Block/Html/Head.php .

Voici une version patchée : http://blog.stockho.com/public/Head.php.new

Voici le fichier original pour information : http://blog.stockho.com/public/Head.php.old

Mise-à-jour de Magento

Il est essentiel, pour se prémunir des attaques, bugs, et pour profiter des améliorations en tous genres, de tenir sa version Magento à jour. D'autant plus qu'il sera beaucoup plus difficile – voire impossible – de sauter d'une version à une autre, sans passer par toutes les versions intermédiaires qui seraient sorties entre temps.

Mettre à jour Magento peut s'avérer risqué, c'est pourquoi il faut se préparer au pire :

  • on sauvegarde la base de données :

    mysqldump -u utilisateur -p"mot_de_passe" nom_de_la_base > sauvegarde_datée.sql

  • on sauvegarde l'intégralité du dossier racine de magento.

Ensuite, on se rend dans le dossier de Magento et, en utilisateur root :

./pear mage-setup . (si la permission est rejetée : chmod 755 pear)
./pear install -f magento-core/Mage_All_Latest-stable
rm -rf racine_magento/var/cache/*
rm -rf racine_magento/var/session/*

Il faudra ensuite penser à recréer le cache à partir de l'interface d'administration et régler les éventuelles nouvelles options de configuration.

Suppression des logs de la base de données Magento

Magento sauvegarde dans sa base de données les informations relatives aux accès au site par les visiteurs.

Dans sa table de log, on trouve les champs log_url, log_url_info, log_visitor et log_visitor_info. Cette table peut grossir considérablement avec le temps, particulièrement sur un site à fort trafic, et affecter les performances du serveur hébergé. Par défaut, l'épuration de cette table n'est pas activée.

Pour l'activer et rélger les différentes options relatives au système de log, il convient de se rendre dans l'interface d'administration, menu Système -> Configuration, puis Système sur la gauche, puis dans l'onglet relatif aux logs.

Sessions Magento en base de données

Il peut être utile de stocker les sessions non plus sur le filesystem, ni même en RAM (cf ce billet), mais directement en base de données. Cela sera particulièrement utile dans le cas d'un environnement hébergé de cluster de base de données (cf ce billet) avec replication et load balancer, afin d'éviter des conflits de sessions entre les différents front offices...

Avec Magento, rien de plus simple : rendez-vous dans le fichier racine_magento/app/etc/local.xml, et changez la ligne
<session_save><![CDATA[files]]></session_save>
en
<session_save><![CDATA[db]]></session_save>

Et voilà.

Changer l'URL d'administration de Magento

Il est extrêmement fréquent -pour ne par dire constant- pour un serveur d'être la cible de scans par des scripts qui balayent de larges plages d'IP et qui testent les URLs d'administration communes telles que http://www.site.com/phpmyadmin ou encore http://www.site.com/admin.

Afin de protéger sa plateforme Magento contre une éventuelle faille favorisée par l'utilisation d'une URL d'administration trop évidente, il est donc conseillé de la changer en quelque chose de plus original.

Cela peut être fait à l'installation, ou plus tard dans le fichier racine_magento/app/etc/local.xml :

  • à l'installation, il suffit de changer le chemin d'administration par défaut ("admin") en quelque chose qui répond à la syntaxe d'une URL.
  • dans le fichier local.xml, changer la ligne <![CDATA[admin]]></frontName> en <frontName><![CDATA[nouveau_nom]]>.

Ne pas oublier de supprimer le cache (rm -rf racine_magento/var/cache/*), puis de le recréer via la nouvelle URL de l'interface d'administration.

Cluster de base de données Magento

Si tout se passe bien pour vous, votre commerce devrait s'étendre jusqu'aux limites du serveur hébergé que vous utilisez.

Lorsque ce moment arrive, que malgré toutes les optimisations mises en oeuvre, l'afflux de visiteurs commence à faire ralentir le site, il est temps de passer à une architecture multi-serveurs.

Tout a déjà été prévu dans Magento pour faciliter la mise en place d'une replication de base de données. Avec une base de données dédiée à la lecture, et une autre, dédiée à l'écriture, un système de réplication entre les deux pour garder les données synchronisées, on peut facilement doubler les capacités au niveau des accès aux données. Imaginez cela couplé à un load-balancing sur plusieurs front office... mais cela fera l'objet d'un autre billet.

Voici un lien expliquant la procédure de mise en place de la réplication, et ici un exemple de configuration du fichier racine_magento/app/etc/local.xml permettant de mettre en place la base de lecture et celle d'écriture :

[...]
       <resources>
            <db>
                <table_prefix><![CDATA[]]></table_prefix>
            </db>
            <default_setup>
                <connection>
                        <host><![CDATA[ip_bdd_ecriture:port]]></host>
                        <username><![CDATA[user]]></username>
                        <password><![CDATA[password]]></password>
                        <dbname><![CDATA[nom_bdd]]></dbname>
                    <active>1</active>
                </connection>
            </default_setup>
            <default_read>
                <connection>
                        <host><![CDATA[ip_bdd_lecture:port]]></host>
                        <username><![CDATA[user]]></username>
                        <password><![CDATA[password]]></password>
                        <dbname><![CDATA[nom_bdd]]></dbname>
                    <active>1</active>
                </connection>
            </default_read>
        </resources>
[...]

default_setup correspond à la base de données d'écriture.

Réparer sa base de données Magento

Il peut arriver, par une erreur de manipulation, d'endommager gravement sa base de données. Heureusement, Varien -l'éditeur à l'origine de Magento- a prévu un système de réparation très poussé.

Allant jusqu'à recréer des tables manquantes, des champs, des indexes... ce script php suppose d'avoir conservé une version saine de sa base de données. Il permet de pointer la base saine et la base endommagée, de les comparer, et de faire les réparations qui s'imposent.

Imaginons un instant que l'administrateur de la plateforme hébergée ait procédé à l'ajout d'un millier de produits, avec les références, les tags, les prix, les descriptions... et que par mégarde il ait supprimé une table. Au lieu de reprendre une version antérieure de la base, et de perdre tout son travail, il lui suffira de réparer la base à l'aide de la structure de la base saine et ce, en quelques secondes.

Voici le lien vers le script, ainsi que la procédure d'utilisation. Ne pas oublier de déplacer/supprimer le script par la suite.

Magento et mpm_worker

Concernant le fonctionnement d'Apache, le module mpm_prefork est le module par défaut. Il est très robuste mais aussi très consommateur de ressources. Chacun de ses processus utilise son propre espace mémoire, chaque nouveau processus réserve un nouvel espace en RAM.

Le module mpm_worker est plus récent, mieux pensé. Beaucoup plus performant, il permet de multi-threader les requêtes, le lancement d'un thread étant beaucoup plus rapide que celui d'un nouveau processus, conservant aussi le même espace mémoire. Il s'agit de l'une des meilleures optimisations possible pour la plateforme Magento hébergée.

La principale raison pour laquelle mpm_worker n'a pas encore remplacé mpm_prefork, est qu'il lui faut utiliser des extensions thread-safe, ce qui n'est pas toujours le cas, notamment avec mod_php. D'où la nécessité d'utiliser fastCGI en lieu et place de mod_php (voir ce billet). À noter que mpm_worker remplace mpm_prefork, et vice versa. Il n'est pas possible de conserver les deux.

Pour l'installer, un apt-get sur une debian ou un ubuntu suffit, sinon il convient de recompiler Apache avec l'option --with-mpm=worker lors du ./configure. Pour vérifier si l'installation a bien fonctionné, utiliser la commande " httpd -l " si tout s'est bien passé, worker apparaîtra dans la liste des modules chargés par Apache.

Magento et FastCGI

Très gourmand en ressources, en RAM notamment, un Magento mal configuré peut facilement épuiser les capacités d'un serveur très puissant.

Le php permet d'ajouter du dynamisme aux pages, mais a besoin d'être généré à la volée pour toute requête. Mod_php, le module php par défaut d'Apache, n'a qu'un défaut : il a été conçu pour fonctionner avec un processus différent pour chaque N requêtes. Ce qui signifie que sur un serveur très chargé, des dizaines de processus mod_php peuvent tourner en même temps, consommant de ce fait la RAM et forçant le serveur à swapper, engendrant d'énormes ralentissements. Ce phénomène est amplifié si le keepalive d'Apache est activé, car même non-utilisé, un processus mod_php resterait en RAM jusqu'à l'expiration du keepalive.

Afin de tirer profit de keepalive, et de sauvegarder la RAM du serveur, nous recommandons, pour votre plateforme hébergée, d'utiliser fastCGI. FastCGI ne lance qu'un nombre déterminé de processus, qui ne change pas. Ils restent en RAM et traitent toutes les demandes liées au php, au déficit de quelques millisecondes de chargement de page, tout en permettant d'utiliser keepalive.

Voir ce lien pour la procédure d'installation.