jan 10

Magento et les imports

Comme souvent, quand vous avez un site Web à faire tourner ou à lancer, vous aller envisager de faire des imports. Que ce soit un one-time ou une automatisation, vous aller vivre avec une limitation de rapidité. Celle-ci est dûe en partie à la structure de la base en EAV et au fonctionnement du Framework.

Cette limite vous borne à un rythme de un a deux secondes par produits à 10/20 produits par secondes selon la méthode utilisée, la machine et la complexité de l’import.

Dès que l’on touche à une grande masse, gagner un peu va jouer beaucoup au final.

Vitaminer un peu vos bases

Désactiver les binlogs

Ce tips est utilisable aussi bien pendant vos imports que sur votre production. Seul petit soucis, sur la production, désactiver les binlogs va vous empécher de faire du master/master ou du master/slave (peut être du cluster je ne sais pas) et ca peut ne pas coller avec vos besoins.

Dans votre fichier my.cnf, pour désactiver les binlogs, vous pouvez passer la ligne sync_binlog=1 à sync_binlog=0.

C’est typiquement utile/faisable pour un mono serveur dédié ou virtualisé avec base de donnée et frontal web sur la même instance/machine.

Innodb_flush_log_at_trx_commit

Deuxième limite, si vous passer la paramètre innodb_flush_log_at_trx_commit à 2, vous aller limiter votre niveau de protection en cas de crash et encore, nous parlons ici de la dernière seconde de transaction. Vos machines sont censées être au chaud dans un datacenter, redondante et un crash arrive très très rarement. Une seconde de transaction, chez vente privée à 8h00 du matin, ca peut faire très mal, mais sur un site un peu plus raisonnable à minuit, ca ne représente en général rien. Le risque est donc très limité, d’autant que de nombreux hoster mette maintenant ce paramètre par défaut.

La doc de Mysql nous dit :
If the value of innodb_flush_log_at_trx_commit is 0, the log buffer is written out to the log file once per second and the flush to disk operation is performed on the log file, but nothing is done at a transaction commit. When the value is 1, the log buffer is written out to the log file at each transaction commit and the flush to disk operation is performed on the log file.

When the value is 2, the log buffer is written out to the file at each commit, but the flush to disk operation is not performed on it. However, the flushing on the log file takes place once per second also when the value is 2. Note that the once-per-second flushing is not 100% guaranteed to happen every second, due to process scheduling issues.

With a value of 2, then only an operating system crash or a power outage can erase the last second of transactions. However, InnoDB’s crash recovery is not affected and thus crash recovery does work regardless of the value.

Il faut savoir que les disques durs et les controlleurs peuvent aussi prendre sur eux de retourner un joyeux « ok c’est fait » alors qu’en fait, la donnée est en cache mémoire en attendant un flush… Mais dans ce cas, le mode 1 n’est pas plus sécurisant, donc autant rester sur le 2.

Pour modifier votre valeur de commit :
passer innodb_flush_log_at_trx_commit = 1 à 2

Résultats attendus

Si vous mettez ces deux valeurs en place, vous devriez avoir un gain de performances pour vos imports mais aussi en exploitation, de 20 à 40% de performances. C’est un choix à bien réfléchir cependant mais un risque limité. Coté binlog, c’est faisable ou non, tout dépend de votre environnement.

écrit par Philippe Humeau \\ tags: , , ,