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.

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à.

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.

Il peut arriver de perdre son mot de passe d'administrateur Magento, de l'oublier, ou de se resservir d'une ancienne sauvegarde de la base de données dont le mot de passe a été perdu depuis.

Il est heureusement possible de le changer manuellement, en passant directement pas la base de données (manipulation également possible par phpMyAdmin, si vous n'avez pas l'accès ssh sur le serveur hébergeant votre site…).

On se connecte donc à MySQL, puis :

mysql > use nom_de_la_bdd;
mysql > SELECT * FROM `admin_user`;

On trouve dans le résultat de cette commande le nom de l'administrateur dont on veut modifier le mot de passe, puis :

mysql > UPDATE `admin_user` SET `password` = MD5('nouveau_mot_de_passe') WHERE `username` = 'nom _administrateur';

La configuration par défaut de MySQL tend à préserver la RAM à outrance. Une plateforme Magento hébergée se doit d'être rapide afin d'assurer le maximum de confort à la navigation, et l'optimisation de la configuration de MySQL y contribue pour beaucoup.

Nous proposons ici quelques rapides réglages à apporter au fichier my.cnf, section [mysqld]:

max_connections = 500
max_connect_errors = 10
key_buffer_size = 32M
max_allowed_packet = 16M
table_cache = 512
sort_buffer_size = 8M
join_buffer_size = 8M
read_buffer_size = 2M
read_rnd_buffer_size = 16M
bulk_insert_buffer_size = 64M
myisam_sort_buffer_size = 64M
myisam_repair_threads = 1
myisam_recover
tmp_table_size = 64M
thread_cache_size = 8
thread_concurrency = 8
wait_timeout = 300
max_heap_table_size = 32M
innodb_additional_mem_pool_size = 16M
innodb_buffer_pool_size = x (ou x = 80% de la RAM sur un serveur dédié, ou 50% sur un serveur non-dédié)

Bien que ces réglages conviendront à la plupart, l'idéal serait d'adapter ces paramètres aux besoins spécifiques de la plateforme Magento en question.

Dans notre protocole de benchmark, on peut remarquer que front office, back office et base de données sont séparés en autant de machines virtuelles. C'est une option qui a été intégrée par les développeurs de Magento pour permettre de répartir la charge entre divers serveurs hébergés.

Il y a deux raisons essentielles à cela :

• La première est une raison tenant à la sécurité. Plus le site est compartimenté, plus il est sécurisé. Dans l'hypothèse ou une faille venait à être exploitée sur l'un d'eux, les deux autres ne seraient pas touchés.
• La seconde est un souci d'optimisation. En effet, cela permet d'allouer à chaque partie du site ses propres ressources, et ainsi de mieux les gérer. Cela met en place une topologie plus souple pouvant aider à la mise en place d'un load balancing, d'une clusterisation... ainsi que d'upgrader, au niveau hardware, une partie du site sans devoir nécessairement toucher au reste.

En plus de cela, cette séparation simplifie considérablement le monitoring, ce qui permet de concevoir des plans d'évolution aussi bien au niveau des performances que de la sécurité.

MySQL intègre un système de cache, pour les requêtes de type SELECT. Il permet de stocker en mémoire, pour une durée relativement courte, le résultat d'une requête, afin de puiser dans son cache le résultat de la-dite requête, si elle est réitérée - rigoureusement à l'identique - peu de temps après, et si la table contenant son résultat n'a pas été altérée entre temps.

Ce procédé n'est pas activé par défaut pour la simple raison qu'il n'optimise l'accès à la base de donnée que pour certaines utilisations : si les tables sont susceptibles de changer plusieurs fois par minutes, le cache engendrera des accès disque pour rien et produira l'inverse de l'effet recherché.

Les accès à la base de données du code de Magento ont été optimisés pour ce système, en séparant les tables de façon réfléchie. Il n'est pas rare de voir un gain de 30% de temps d'accès après l'activation du cache MySQL. Pour l'activer, il convient d'ajouter au fichier my.cnf, section [mysqld], les lignes suivantes :

query_cache_type = 1
query_cache_size = 64M
query_cache_limit = 2M

Les valeurs sont évidement à adapter en fonction des capacités de la plateforme hébergée.

Une des plus grandes forces de Magento est d'être open-source. Entre autres avantages, cela permet à la communauté de conjuguer ses efforts pour améliorer le code, développer des extensions, mais aussi faciliter l'entre-aide.

Pour autant, cette force peut se révéler être une faiblesse dans le domaine de la sécurité : en partant du principe que tout le monde partage le même code, on peut aisément conclure que tout le monde partage les mêmes failles de sécurité. De sorte que les injections SQL, relativement fréquentes, sont grandement facilitées lorsque l'attaquant connait le nom des tables de la base de données.

Contre cela, Magento intègre un verrou de sécurité, permettant d'utiliser un préfixe pour les tables de la base. Mais cela n'est pas activé par défaut. Cette décision doit être prise conjointement entre l'hébergeur du site magento et l'intégrateur.

Du côté de Magento, il est possible de le faire à l'installation, mais aussi plus tard, dans le fichier racine_magento/app/etc/local.xml, il convient d'insérer le préfixe comme suit :

<table_prefix><![CDATA[votre_préfixe]]></table_prefix>