php magento

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.

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.

eAccelerator et Magento

Alternative pour la gestion du cache php, eAccelerator semble donner un gain de 10% à 20% supérieur à APC sur une plateforme Magento (voir les benchmarks).

La procédure d'installation est la suivante :

  • télécharger les sources sur le site officiel ;
  • configuration, compilation et installation avec cette série de commandes :
    phpize
    ./configure --with-eaccelerator-shared-memory --with-eaccelerator-sessions --with-eaccelerator-content-caching --with-php-config=PATH
    (pour le PATH : whereis php-config)
    make && make install
  • ajouter les lignes suivantes dans php.ini :

    [eaccelerator]
    extension="eaccelerator.so"
    eaccelerator.shm_size="128"
    eaccelerator.cache_dir="/tmp/eaccelerator" 
    (créer le dossier et chmod 777)
    eaccelerator.enable="1"
    eaccelerator.optimizer="1"
    eaccelerator.check_mtime="1"
    eaccelerator.debug="0"
    eaccelerator.filter=""
    eaccelerator.shm_max="0"
    eaccelerator.shm_ttl="0"
    eaccelerator.shm_prune_period="0"
    eaccelerator.shm_only="0"
    eaccelerator.compress="1"
    eaccelerator.compress_level="9"

Puis redémarrer Apache.

Ensuite, éditer/ajouter les lignes suivantes dans racine_magento/app/etc/local.xml :

<cache>
    <backend>eaccelerator</backend>
    <prefix>alphanumeric</prefix>
</cache>

Il faudra penser à rafraichir le cache depuis l'interface d'administration du site hébergé.

Compilation intermédiaire du code PHP de Magento

Sans optimisation de ce côté, le serveur doit repasser par toutes les phases de compilation / interprétation du langage PHP pour chacune des pages du site.

Il existe des gestionnaires de cache de compilation intermédiaire du code PHP, tel que APC, qui soulagent la charge processeur du serveur en mettant en cache le code PHP dans un format de code binaire intermédiaire, ce qui épargne à l'interpréteur de recompiler l'intégralité du code PHP à chaque requête. Il s'agit de l'une des meilleurs optimisations possible pour Magento, du fait de l'importance du PHP dans son code.

La première chose à faire est d'installer APC :
par exemple sous Debian : apt-get install php-apc

Puis, dans php.ini, d'ajouter les lignes suivantes :

[apc]
apc.enabled="1"
apc.ttl="7200"
apc.user_ttl="7200"
apc.shm_segments="3"
apc.shm_size="128"

Et enfin, de redémarrer Apache.

Bien que nous recommandons – pour des raisons d'optimisations – d'utiliser le système de fichier tmpfs pour cela (voir ce billet), il est possible d'utiliser APC comme cache du dossier racine_magento/var/cache. Pour se faire, il convient de se rendre dans le fichier racine_magento/app/etc/local.xml et d'y ajouter les lignes suivantes, juste en dessous de <global> :

<cache>
    <backend>apc</backend>
    <prefix>alphanumeric</prefix>
</cache>

(dans le cas ou plusieurs Magento/sites web tourneraient sur le serveur d'hébergement, il faut remplacer alphanumeric par un préfixe unique, cela permet de différencier les caches d'APC afin de ne pas mélanger les données entre les sites).

Expiration du cache Magento

Tous les navigateurs s'appuient maintenant sur des systèmes de caches. Ils les utilisent dès que cela s'avère possible, afin d'accélérer l'accès aux pages web, de limiter l'usage de la bande passante...

Le problème est que le navigateur ne sait pas forcément lorsqu'il doit rafraîchir la page depuis le serveur web. Dans le doute, il la rafraîchit, ce qui annihile l'utilité du cache. Pour savoir lorsqu'il doit aller chercher la page dans son cache plutôt que sur le web, il s'appuie sur deux en-têtes HTML : expiration et contrôle du cache.

Ces deux en-têtes sont réglés, en fonction des recommandations d'optimisation de Yahoo!, dans le fichier .htaccess de de la plateforme Magento hébergée ; cependant, ils ne sont pas activés par défaut. Pour les activer, les lignes suivantes sont à ajouter dans le fichier de configuration de apache (la plupart du temps /etc/apache2/apache.conf) :

<IfModule mod_expires.c>
ExpiresActive On
</IfModule>

Si vous n'avez pas accès à la configuration d'Apache, il est possible d'ajouter ces lignes au .htaccess à la racine de votre site, mais il faudra penser à les rajouter au nouveau .htaccess lors des mises-à-jour de Magento.