Introduction

Après avoir hébergé un bon millier de sites et, parmi ceux-ci, une majorité de sites Magento, après avoir également mené une R&D constante sur le sujet de l’optimisation des performances, ce « Howto d’optimisation de Magento » synthétise un certain nombre de best practices autour de l’optimisation de Magento. Ceci étant posé, un certain nombre de points sont transposables à n’importe quel site réalisé en PHP.

J’ai pu oublier certains points ou commettre des fautes de frappes ou de compréhension, n’hésitez pas à me le signaler. (philippe.humeau[@]nbs-system.com)

Licence

Il est distribué sous licence Creative Commons.  

Contrat Creative CommonsMagento optimization howto de Philippe Humeau – NBS System est mis à disposition selon les termes de la licence Creative Commons Paternité – Pas d’Utilisation Commerciale – Pas de Modification 3.0 non transcrit. Les autorisations au-delà du champ de cette licence peuvent être obtenues à www.nbs-system.com/contact.

La reproduction partielle ou complète de ce document sur un autre site que celui de NBS System est interdite.

Pourquoi donner toutes ces informations

« Pourquoi donner ces éléments d’optimisation à tout le monde, y compris vos concurrents ? »

1)       Magento nous a apporté beaucoup de business. La communauté autour de ce produit nous a aussi envoyé beaucoup de « good vibes », nous avons voyagé et grandit grâce à ce produit et comme nous ne sommes pas développeurs, voici la forme sous laquelle nous contribuons.

2)       Ce Howto est une photo. Il est optimal (ou presque) au moment de sa publication mais les choses évoluent dans le temps et notre travail est d’avoir toujours une longueur d’avance pour apporter à nos clients le meilleurs des performances.

3)       Si vous avez l’intention d’héberger vos serveurs vous-mêmes, nous ne perdons pas un client en vous montrant quelques pistes d’optimisation. Nos clients ont besoin de service, ils viennent pour que nous nous occupons de tout pour eux, le jour comme la nuit, sur une infrastructure sécurisé et redondante, nous leur apportons donc bien plus que juste de la performance.

4)       Nous avons encore quelques petits secrets en réserve ;)

D’ailleurs, si vous avez besoin d’un infogérant pour vos sites de Ecommerce (et pas seulement Magento), nous serons ravis de vous accompagner.

Le système de cache de Magento

Magento & Zend Framework

Avant de toucher à d’autres points, il est important de se pencher en premier sur le système de caches de Magento.

Magento repose sur un système de cache hérité de celui de Zend Framework (ZF). Rien de bien étonnant à cela puisque les deux sociétés sont proches et que Magento est un Framework reposant sur Zend. En d’autre mot, c’est un Meta Framework, un Framework au-dessus d’un autre.

Le système de cache Zend est décrit ici : http://framework.zend.com/manual/en/zend.cache.backends.html

Vous verrez à la lecture de ce manuel que l’on retrouve un grand nombre de similarités entre le cache du ZF et celui de Magento.

Le principe de Two Level cache

[Merci à Fabrice Beck et Matthieu Bouchot de la E-commerce Academy pour ces informations]

Le système de « two level cache » propre à Zend et utilisé par Magento permet d’avoir un cache rapide et un cache lent. Le soucis en l’occurrence c’est que seul les slow backend de cache en format file (fichier) ou database permettent aux développeurs de stipuler un format étendu « maison ».

Avec un Memcache ou un APC, on peut rentrer de la données mais uniquement dans une association simple. Pour pouvoir fonctionner, les systèmes comme Magento ont besoin d’un slow backend structuré « maison » pour pouvoir associer une clef de cache et un id. Dans le fast_backend, on met un id et le contenu du cache. Avec ce principe, lors d’une demande d’effacement de cache, on peut faire un tri sélectif et n’effacer qu’une clef ou une catégorie et pas tout le cache massivement.

D’un côté l’index est détaillé dans le slow backend, de l’autre le contenu du cache en lui-même est contenu dans le fast backend. Si l’on impose un slow backend « non structurable » à Magento, il ne pourra pas effectuer de nettoyage sélectif et devra invalider tout le cache à chaque manipulation, ce qui rend inopérant le mécanisme de cache.

Les Ramdisks et les SSD

Déclarer un « file » backend, que ce soit en slow ou en fast, ce n’est pas la fin du monde, loin de là.

En effet, stocker sur disque est lent. Mais rien ne vous oblige à écrire un cache de type file sur le disque dur. Vous pouvez très bien le monter sur un RAMDISK, qui lui est très performant. Avec de la DDR3, votre disque dur est 100 à 300 fois plus lent que votre mémoire vive. Avec la chute des prix de ces composants, il est facile d’avoir 12 ou 24 Go de RAM, pourquoi s’en priver ?

Du coup, il devient plus que pertinent d’utiliser un Ramdisk et d’y stocker le slow backend (et éventuellement) le fast backend. En fait, si l’on utilise Memcache, ce n’est pas pour aller plus vite, c’est juste pour pouvoir partager l’information contenu dans le memcache entre plusieurs serveurs. Mais en pratique, avec un seul serveur, il vaut mieux utiliser un backend de type « file » et l’écrire sur un ramdisk.

Sous linux, c’est simplissime :

mkdir –p /dev/shm/cachechown –R www-data.www-data /dev/shm/cache
mount –o bind /dev/shm/cache /var/www/magento/site_test/var/cache

Je  vous conseille bien sûr de mettre ça dans vos fichiers de démarrage dans le /etc/init.d pour que ce soit toujours en place au boot et de bien nettoyer et fermer proprement vos ramdisks au moment du shutdown.

Bien sûr, vous pouvez aussi y mettre vos sessions,  vos logs, tout ce qui vous parait être accéder en écriture régulièrement en fait. Dans le cadre des logs, une petite copie vers le support physique toute les 10 minutes s’impose, ça reste un ramdisk, on ne veut pas tout perdre en cas de reboot.

Vous allez déjà constater une belle montée en performance.

Pour la base de données, c’est un peu plus compliqué. Tout mettre en ram, c’est un gros pari en cas de reboot ou de plantage. Mais avec un petit commit de  temps en temps sur le disque ou une synchronisation vers le disque sur une DB slave par exemple à travers le mécanisme de binlog, vous pouvez l’envisager. Sinon, le SSD peut offrir une bonne solution malgré son coût prohibitif et le fait qu’il n’est pas encore très robuste dans le temps et donc que vous allez devoir les avoir en RAID1 au minimum.

Vous pouvez aussi montez vos disque en taille fixe avec tmpfs :

mount tmpfs /path/to/magento/var/session -t tmpfs -o size=64m
mount tmpfs /path/to/magento/var/cache -t tmpfs -o size=64m

Le paramétrage du cache de Magento

Beaucoup d’incompréhensions se sont glissées chez beaucoup de personne autour de ce  cache. Commençons par analyser le fichier local.xml et ce qui est lié à la déclaration de cache dans celui-ci.

Depuis la version 1.4 CE de Magento, le système est séparé en deux couches, slow et fast backend.

Attention, certains réglages, notamment ceux concernant , ne sont disponibles que depuis la 1.5.0.0-beta 2, il faut donc faire votre configuration en fonction de ce qui est possible dans votre version.

Le cache peut servir à stocker plusieurs données dans Magento :

  • Le cache des blocs
  • Le Full Page Cache
  • Toute autre donnée qu’un développeur aura correctement poussé dans les caches avec une extension (par exemple Nitrogento) en respectant le mécanisme sous-jacent en ne faisant appel qu’à des méthodes de Magento pour s’adresser à son cache

Le fichier de paramétrage se trouve dans app/etc/local.xml. Ce fichier contient des balises XML pour paramétrer différents aspects de Magento, dont le cache. En l’occurrence, les paramètres liés au cache se trouve entre les balises et .

Il est possible de déclarer plusieurs types pour le Fast et pour le slow backend. De même, il est possible de passer des paramètres supplémentaires pour ces items. Les valeurs implicites (non déclarées ne me sont pas connues mais je recommande toujours une déclaration explicite pour éviter tout doute).

Dans le local.xml, on a plusieurs clefs XML importantes :

memcached

Si on ne precise que Backend, le backend Fast sera Memcached (en l’occurrence) et le slow automatiquement la base de données. Il est possible évidemment de déclarer explicitement le fast_backend : memcached

Il semble que et ait le même effet, ils décrivent tout deux quel type de FastBackend va être utilisé. Ici, Magento attend une valeur parmi les suivantes :

  • memcached
  • file
  • apc
  • ou encore sqlite, xcache, eaccelerator, database

database          

Ce paramètre, qui s’occupe du Slow Backend, peut prendre les valeurs suivantes :

  • file
  • database
  • memcached
  • apc
  • ou encore sqlite, xcache, Varien_Cache_Backend_Eaccelerator, Varien_Cache_Backend_Database

Les deux derniers me sont inconnus, ils sont peut être liés à Magento Go ? Je vois bien le principe de fond d’Eaccelerator mais pas trop en quoi il devrait avoir une grammaire particulière et pour Varien_Cache_Backend_Database, je ne vois pas en quoi il faudrait une entrée autre que juste database au final ?

En pratique, seul les slow backend de type file ou database peuvent être réellement efficace pour permettre à Magento de gérer efficacement son cache.

Une incompréhension classique est que le Slow Backend serait un backend de débordement dans le cas où le Fast Backend serait à 80% plein. En fait c’est partiellement vrai mais ce n’est pas uniquement comme cela que ce système fonctionne. Le slow backend sert aussi à stocker les tags des éléments en cache dans le fast backend alors que le fast sert les clefs de cache. Si vous n’avez pas de slow ou que vous le désactivez, cela va impacter le fast backend car Magento ne pourra retrouver les bons tags et gérer correctement les clefs de cache dans le fast backend.

Par contre, on ne veut pas écrire du cache de données dans le slow backend car c’est la partie du cache la plus lente et cela réduirait les performances. Il est possible de ne pas le faire, tout en gardant le slow backend efficace :  <slow_backend_store_data>0</slow_backend_store_data>

Ce paramètre indique à Magento qu’il ne doit pas stocker de données dans le slow mais ne le désactive pas pour autant.

Notez que le cache à 2 niveau possède une option auto_refresh_fast_cache, elle ne fait que remettre en cache les données chargées depuis le cache repoussant ainsi sa date d’expiration. Cela ne se fait que si le taux d’utilisation du fast cache est < 80%. À chaque chargement d’une donnée, il rafraichit le contenu, ce qui n’est pas souhaitable. <auto_refresh_fast_cache>0</auto_refresh_fast_cache>

Mettre cette valeur à 0 permet donc de maintenir un peu plus longtemps un cache actif et surtout de ne pas le rafraichir à chaque load.

Le fast_backend peut prendre des options et elles sont très importantes. Notamment le paramètre lifetime change beaucoup de chose. En effet, s’il est laissé à sa valeur par défaut, le cache expire au bout de 7200 secondes (2 heures), divisé par 3 (on va en reparler) !

Le second paramètre qui joue est la priorité mais elle est fixe et non paramétrable. Si on allonge la durée de vie du cache à 86400 secondes par exemple, on obtient un cache de level 1 (fast cache), beaucoup plus performant et appelé en continu, qui ne tombe pas en carafe toutes les 2 heures, enfin toutes les 40 minutes car la méthode de calcul du temps de durée de vie est : Fast_backend cache lifetime=(lifetime/(11 – priority))

Priority est toujours fixé à 8 et n’est pas éditable par le fichier local.xml. Donc le fast backend lifetime est  toujours divisé par 11-8 (soit 3) par rapport au réglage lifetime déclaré dans le local.xml. Le cache de Zend par défaut est mis à 30 jours sur ce sujet mais Magento le surcharge à 40 min, en fait à 7200 secondes divisé par 3.

Si on met dans les (ou <backend_options>) : <lifetime>86400</lifetime>

On se retrouve avec un cache qui expire toutes les 8 heures (86400/3/3600) au lieu de toutes les 40 minutes… C’est un peu mieux ! On pourrait pousser à 24 heures si le site est dans un cycle de production normal, soit un lifetime de 259 200.

Memcached est capable de compresser les données stockées dans le cache niveau 1 au besoin, si cela peut permettre de garder plus de cache et d’éviter de saturer le level 1, le coût n’est pas si important en terme de CPU.  <compression>1</compression>

Un local.xml optimisé

On aurait tout intérêt, sur un serveur bien taillé, à mettre des options en place :

Si je devais proposer un local.xml optimisé et que vous avez une version CE 1.5.0.0-B2 ou supérieur (ou une EE qui soit 1.10+), je vous donnerai celui-ci :

[Merci à Adrien Urban de NBS System pour les informations de versions et de valeur par défaut d'expiration du cache de Zend et de Magento]

Dans le cas d’une infrastructure avec plusieurs front servers, je recommande ceci  (Magento version EE 1.9+ ou CE 1.5+) :

<cache>           
<backend>memcached</backend>           
<slow_backend>database</slow_backend>
<slow_backend_store_data>0</slow_backend_store_data>
<auto_refresh_fast_cache>0</auto_refresh_fast_cache>
<lifetime>259200</lifetime>
<backend_options>
<servers>
<server>
<host><![CDATA[10.1.1.1]]></host>
<port><![CDATA[11212]]></port>
<persistent><![CDATA[1]]></persistent>
<weight><![CDATA[2]]></weight>
<timeout><![CDATA[5]]></timeout>
<retry_interval><![CDATA[5]]></retry_interval>
<status><![CDATA[1]]></status>
</server>             
</servers>
<compression><![CDATA[1]]></compression>
</backend_options>
</cache>

Si vous utilisez un serveur seul, je vous recommanderai plus ceci (avec un RAMdisk pour cacher les fichier) (Magento version EE 1.9+ or CE 1.5+) :

<cache>           
<backend>file</backend>           
<slow_backend>file</slow_backend>
<slow_backend_store_data>0</slow_backend_store_data>
<auto_refresh_fast_cache>1</auto_refresh_fast_cache>
<lifetime>259200</lifetime>
</cache>

Pour une configuration de riche car il faut pas mal de mémoire sur le memcache et on peut alors désactiver la compression du memcache pour de la performance optimale. La désactiver (passage de la valeur à 0) ne devrait pas notoirement affecter la performance mais par contre, cela devrait diminuer la mémoire disponible considérablement.

Pour le cas d’un site sur un serveur autonome (qui n’est pas en multiple frontal), il peut être pertinent de passer le fast_backend en APC et le slow backend en DB ou en file sur un ramdisk.

Pour les versions pré 1.5.0.0b, une solution relativement propre existe : AOE cache cleaner, à lancer toutes les heures en CRON. L’article de Fabrizio Branca vous donnera plus d’information.

Memcached : soyez prudent malgré tout

[Merci à Emile Heitor (NBS System) pour ces informations]

Quand la librairie memcached et le serveur sont dans une version inférieure à 3.0.3, il semble que le calcul du remplissage du fast_backend soit erroné et que, du coup, on tombe en permanence dans le slow.

Imports Magento lents ?

Un import sous Magento, c’est lent. C’est très lent même mais on peut optimiser ces imports Magento en terme de vitesse de traitement.

Pendant que vous importez vos données, il est important de désactiver totalement les caches de Magento qui ne feront que vous faire perdre du temps (double traitement, insertion d’un élément puis invalidation) et n’amélioreront en rien vos performances. Le temps de traitement varie du 3 au quadruple selon la configuration.

Par ailleurs, vous pouvez aussi désactiver temporairement le mécanisme de binlog qui synchronise une base de données master et un autre master ou un slave dans Mysql. Ça ne fera pas de mal, la synchro peut s’opérer en une fois après coup ou par un import massif dans le second serveur. Vous pouvez aussi passer la variable innodb_flush_log_at_trx_commit à la valeur 2 dans votre fichier my.cnf pour plus de performances.

Enfin, si vous avez vraiment l’intention de mettre un turbo à vos imports, faites-les dans un ramdisk (montez la base de données sur un ramdisk) ou sur un SSD.

Attention : si vous appliquez toute cette formule, vous devriez multiplier la vitesse de vos imports Magento par un facteur 5 à 10 !

Nitrogento


Nitrogento optimise énormément de chose pour vous, très simplement depuis votre backoffice et fournit du Full Page Cache, de nouveaux blocs cache, ainsi que 5 autres optimisations clefs pour votre Magento : www.nitrogento.com

Le code, le code, le code

[Merci à Olivier Ouin de Baobaz pour cette partie de l'explication]

Il est important de comprendre que le code et la qualité du template font toujours l’essentiel de la performance. En matière de Magento, il faut éviter des pièges classiques. Par exemple la gestion du cache n’est pas implicite dans Magento, il faut faire ses déclarations et abonnements explicitement.

Si l’on n’abonne pas correctement un block à un tag, le cache de ce bloc sera invalidé dès que l’on touche au contenu de celui-ci, même si la modification intervient sur un élément qui ne le concerne pas. Si l’on modifie un produit, au moment de l’effacement des clefs associés à ce catalog_product et du tag du produit, tout le bloc caché lié au tag sera aussi enlevé du slow backend et du fast backend.

Si l’on abonne les blocks à des tags trop génériques, comme catalog_product au lieu de quelque chose de plus précis (catalog_product_xx), le cache de ce bloc sera trop souvent invalidé inutilement.

Par exemple, le cache d’un bloc présentant des attributs produit sera sur une page produit qui serait abonné à CATALOG_PRODUCT sera effacé si une modification intervient sur la catégorie, même si il n’a rien avoir avec le produit.

A l’inverse, si l’on ne configure pas correctement les caches de blocks, qu’ils ne sont pas abonnés aux bons tags pour qu’ils soient rafraichit en fonction des actions dans le back office, on va se retrouver avec un cache périmé à l’écran.

Si l’on surcharge les en têtes HTTP en y mettant des instructions qui perturbent les reverse proxy, cela peut aussi provoquer des résultats de cache aberrants, un cache infini ou même le fait de servir des pages contenant des données de sessions aux mauvaises personnes.

Allez plus loin dans l’optimisation de Magento

Au-delà de cette première étape, vous pouvez agir sur de nombreux points, en voici quelques-uns :

Matériel

Les fabricants ont des performances comparables entre IBM/Dell et HP. Nous avons choisis HP pour son intégration plus poussé que Dell mais les serveurs IBM restent performants et très durables et les serveurs DELL très abordables. Par contre, les processeurs Intel sont plus performants en matière de traitement que les AMD sur les frontaux Web, alors que les AMD sont aussi efficaces et moins cher pour les bases de données.

N’oubliez pas de paramétrer votre Bios ou au moins d’y jeter un oeil car beaucoup de serveurs sont livrés avec des Bios réglés par défaut en économie d’énergie, ce qui impact beaucoup les performances. Vous pouvez faire ce réglage sous Linux afin de ralentir automatiquement les processeurs lors des périodes de basses charge mais ne laisser pas le Bios le faire lui même.

Paramétrage du serveur          

Au niveau du noyau, je vous conseille de faire un tour dans les différents scheduler du noyau et d’en choisir un optimal et d’éliminer tout ce qui ne sert à rien. Vous pouvez également le mettre en full statique et ajouter GRSec/Pax pour votre sécurité. Enfin, installez également Irqbalance pour ventiler vos IRQ sur tous les cores et pas un seul.

Sur votre système de fichiers, monter les partitions Web et logs en « noatime » (no access time) ce qui évite des écritures inutiles sur disques. En effet cela ne sert à rien sur des fichiers Web de savoir quand logo.jpg a été accéder pour la dernière fois par un visiteur… (Idem pour noadirtime)

/var/www ext3 defaults,grpquota,noatime,nodiratime,data=ordered 0 2

Paramétrage du serveur Web

Si vous utilisez Apache, voici quelques valeurs clefs.

Timeout 120              # Two minutes is more than enough to tell it's a timeout
KeepAlive on             # keepalive help to improve loading times
MaxKeepAliveRequests 100 # but consume resources so we have to limit it
KeepAliveTimeout 15      # and short timing help maintain the RAM load not too high
HostnameLookups Off      # cost resources, sockets and can be treated later on
   
StartServers           5 # Yes, mpm_prefork, it consumes RAM but is fast & reliable   
MinSpareServers        5 # especially when you are not sure that all your modules
MaxSpareServers       10 # are threadsafe. We start 10 servers and allow it to grow
ServerLimit          500 # up to 500. Not too much request per child in order to
MaxClients           256 # avoid D.O.S    MaxRequestsPerChild 1000

Avoir Nginx comme serveur Web peut aussi vous fournir de très bonnes performances (~+20%) mais Nginx n’est pas officiellement supporté par Magento et vous allez devoir gérer vos .htaccess autrement.

D’une manière générale, on gagne pas mal aussi à regrouper tous les .htaccess éparpiller dans le source tree de Magento en un paquet de directive directement dans le fichier Vhost de Magento pour éviter de lire à chaque fois tous les fichiers.

Pensez à nettoyer de temps en temps les veilles sessions si elles sont sur disques :

find /path/to/session/* -mtime +5 -exec rm {} \;

Dans le fichier Vhost ou dans un .htaccess, vous pouvez ajouter cela :

  ExpiresActive on
  ExpiresByType image/jpg "access plus 6  months"
  ExpiresByType image/png "access plus 6  months"
  ExpiresByType image/jpeg "access plus 6  months"
  ExpiresByType image/gif "access plus 6  months"
  ExpiresByType image/png "access plus 6  months"
  ExpiresByType text/ico "access plus 6  months"
  ExpiresByType image/ico "access plus 6  months"
  ExpiresByType image/icon "access plus 6  months"
  ExpiresByType image/x-icon "access plus  6 months"
  ExpiresByType application/x-shockwave-flash  "modification plus 6 months"
  ExpiresByType text/css "access plus 1  week"
  ExpiresByType text/javascript "access  plus 1 week"
  ExpiresByType text/html "modification  plus 1 week"
  ExpiresByType text/xml "modification  plus 2 hours"
  ExpiresByType image/vnd.microsoft.icon  "access plus 6 months"
  ExpiresDefault "access plus 1 week"
  #Header set Cache-Control  "max-age=86400, public"
  Header set Cache-Control  "max-age=2592000, public"
  Header set Cache-Control  "max-age=2592000, private"
  Header set Cache-Control "max-age=7200,  public"
  Header unset Cache-Control
  BrowserMatch ^Mozilla/4  gzip-only-text/html
  BrowserMatch ^Mozilla/4\.0[678] no-gzip
  BrowserMatch \bMSIE !no-gzip  !gzip-only-text/html
  BrowserMatch \bMSI[E] !no-gzip  !gzip-only-text/html
  Header append Vary User-Agent  env=!dont-vary
  AddOutputFilterByType DEFLATE text/css  application/x-javascript text/x-component text/html text/richtext image/svg+xml  text/plain text/xsd text/xsl text/xml image/x-icon<
  FileETag MTime Size

Vous allez gagner un temps fou car les navigateurs de vos visiteurs vont cacher les données et arrêter de demander les mêmes éléments en permanence à votre serveur web alors qu’ils les ont déjà reçu.

Reverse proxy

Un reverse proxy améliore considérablement les performances en stockant un cache des fichiers statiques et des blocs HTML. Varnish et Nginx excellent tous les deux dans ce domaine, même si vous l’installez en local sur votre serveur et pas sur un serveur séparer, cela vous aidera déjà beaucoup.

Serveur de média & CDN

Séparer vos médias sur un serveur différent peut apporter deux avantages. En premier lieu, cela décharge le serveur frontend de Magento d’un traitement inutile, en second lieu cela permet de distribuer plus vite les contenus statiques aux navigateurs à partir de plusieurs CNAME différent et pas d’un point unique. En général les navigateurs parallélise alors une dizaine de requêtes par CNAME pour ramener plus vite tous les éléments.

Paramétrage de PHP

Je ne vais pas mettre un fichier complet php.ini, voici juste les valeurs importantes.

output_buffering = 4096
max_execution_time = 30
max_input_time = 60memory_limit = 128M
default_socket_timeout = 60
pdo_mysql.cache_size = 2000
mysql.allow_persistent = On

Attention, mettre ici ou dans le fichier .htaccess de Magento des valeurs très hautes pour le php_memory_limit est une erreur commune. Dépasser les 256 Mo est déconseillé, tout simplement car si un processus PHP, une page ou une cron, se met à surconsommer, elle pourra prendre, par exemple 2 Go si vous fixer la memory_limit à cette valeur. 4 threads et hop, plus de mémoire, on se met à swapper et tout devient lentissime. Mieux vaut optimiser ou corriger son code plutôt que de faire exploser cette valeur.

Paramétrage de la base de données

Si vous avez pour objectifs de mettre des milliers de core dans votre serveur de base de données en mysql 5.1 ou avant, cela ne sert à rien, à l’heure actuelle, Mysql ne tire pas partie de plus de 4 cores. Multiplier les serveurs au besoin mais pas les cores. [merci à Mattieu Guegan de Virtua pour l'info sur la version de Mysql et sur la confirmation des performances de Percona]

Quelques configurations utiles pour le paramétrage de votre Mysql ?

Innodb_buffer_pool_size = 3 Go
# 66% of the available memory # (3 Go on a 8 Go ram server housing web and database for exemple)
Innodb_thread_concurrency = 8   # 2 * (total number of cores)        
Thread_cache_size = 32
Max_connections = 512 # (should be enough, (max simultaneous connection + 1 * 1,5))
Thread_concurrency = 8Table_cache = 1024 # (should be enough for everybody...)
Query_cache_size = 128M
Query_cache_limit = 2M
Sort_buffer_size = 8M
innodb_flush_log_at_trx_commit = 2 # (safe vs speed, 0 speed, 1 safe, 2 mixed)
innodb_log_buffer_size = 16M
innodb_log_files_in_group = 2
innodb_additional_mem_pool_size = 16M
innodb_log_file_size = 512
Minnodb_log_files_in_group = 2
join_buffer_size = 8M
tmp_table_size = 64M
key_buffer = 32M
innodb_autoextend_increment=512
innodb_data_file_path = ibdata1:3G;ibdata2:1G:autoextend
max_connect_errors = 10
table_cache = 1024
max_allowed_packet = 16M
max_heap_table_size = 64M
read_buffer_size = 2M
read_rnd_buffer_size = 16M
bulk_insert_buffer_size = 64M
myisam_sort_buffer_size = 128M
myisam_max_sort_file_size = 10G
myisam_max_extra_sort_file_size = 10G
myisam_repair_threads = 1myisam_recover

Le backend de DB plus performant actuellement pour Mysql est innodb plugin (le innodb buildin est moins performant). Percona offre aussi de sérieuses performances et permet le backup à chaud.

Magento

  • N’oubliez pas d’activer les caches
  • Activez le mage_compiler
  • Désactivez le mode debug (qui tue les performances)
  • Activez le flat catalog
  • Passez le search engine en mode fulltext

La sécurité de votre site Magento

Le meilleur dispositif à ce jour reste NAXSI. http://code.google.com/p/naxsi/ qui est un module Nginx de WAF, gratuit et opensource. Il ne consomme pas les ressources du serveur Web comme peut le faire Mod_security et permet de faire du Whitelisting. Naxsi a été intégré dans les projets OWASP :

https://www.owasp.org/index.php/Projects/OWASP_NAXSI_Project/Releases/Naxsi-alpha-v0.2

Voici quelques autres outils:

  1. Mettez votre local.xml en chmod 500
  2. Filtrez tous les accès à votre serveur sur des IP précises, sauf les 80 et 443
    #/bin/bash
    /sbin/iptables -P INPUT DROP
    /sbin/iptables -P OUTPUT ACCEPT
    /sbin/iptables -I INPUT -s xxx.xxx.xxx.xxx -p tcp –dport 22 -j ACCEPT
    /sbin/iptables -I INPUT -p tcp –dport 80 -j ACCEPT
    /sbin/iptables -I INPUT -p tcp –dport 443 -j ACCEPT  
    
  3. Installez et paramétrez GRsec/PAX
  4. Utilisez des certificats SSL valides (pas self signed), fournit par un éditeur sérieux
  5. Mettez un vrai mot de passé complexe sur votre backoffice
  6. Maintenez votre version de Magento à jour et appliquez les patchs de sécurité
  7. Appliquez les patchs de sécurité de vos outils (apache, php, ssh etc.)
  8. Ajoutez un fichier htaccess (ou dans le httpd.conf) pour limiter l’accès à phpmyadmin et à votre backoffice. (ne mettez pas « limit get, post » car cela permet de contourner cette sécurité essentielle)
      AuthUserFile /path/to_file
      AuthName « Admin area »
      AuthType Basic
      Order allow,deny
      allow from xxx.xxx.xxx.xxxx
      Require valid-user
      Satisfy any
    
  9. Souvenez-vous de filtrez les champs de vos formulaires (et d’utiliser Naxsi)
  10. Faite auditer votre site par une société de professionnels du test d’intrusion ou de la revue de code avant la mise en production
  11. Ajoutez dans vos fichiers de configuration Apache :
      ServerTokens Prod   # the less they know, the better
      ServerSignature Off # same concept
    
  12. Si vous n’avez pas le temps de mettre Naxsi en place , utilisez au moins apache mod_security, voici une configuration de base :
SecFilterEngine On
SecFilterDefaultAction "deny,log,status:403"
SecFilterScanPOST On
SecFilterCheckURLEncoding On
SecFilterCheckUnicodeEncoding Off
SecFilterForceByteRange 1 255
SecAuditEngine RelevantOnly
SecAuditLog logs/audit_log
SecFilterDebugLog logs/modsec_debug_log
SecFilterDebugLevel 0
SecFilterSelective REQUEST_METHOD "!^(GET|HEAD)$" chain
SecFilterSelective HTTP_Content-Type "!(^application/x-www-form-urlencoded$|^multipart/form-data;)"
SecFilterSelective REQUEST_METHOD "^POST$" chain
SecFilterSelective HTTP_Content-Length "^$"
SecFilterSelective HTTP_Transfer-Encoding "!^$"
SecFilter /etc/passwdSecFilter /bin/ls
SecFilterSelective REQUEST_METHOD "TRACE"
SecFilterSelective THE_REQUEST "/etc/shadow"
SecFilterSelective THE_REQUEST "/bin/ps"SecFilter "\.\./"
SecFilterSelective THE_REQUEST "wget "
SecFilterSelective HTTP_USER_AGENT "DTS Agent"
SecFilter "delete[[:space:]]+from"
SecFilter "create[[::space:]]+table"
SecFilter "update.+set.+="
SecFilter "insert[[:space:]]+into"
SecFilter "select.+from"
SecFilterSelective ARGS "drop[[:space:]]+database"
SecFilterSelective ARGS "drop[[:space:]]+table"
SecFilter "<  SecFilter ""SecFilter ""
SecFilter

« Merci à toute l’équipe de NBS System pour avoir apporté leur aide et à nos amis citer dans l’article sur les points précis auxquels ils ont contribués. Si ce Howto vous a été utile, vous pouvez remercier l’équipe en envoyant quelques bières à NBS System, 140 bd haussmann, 75008 Paris, France.

Laisser un commentaire