sept 21

J’ai enfin eu le temps de le terminer, j’espère qu’il vous sera utile, vous pourrez le trouver ici :

http://www.nbs-system.com/blog/magento-optimization-howto.html

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

mai 19

Foreword

After some months in the field of Magento managed hosting, NBS System decided to create a new Magento extension : Nitrogento.

This extension aims at giving more performances to Magento shops. Mainly, 7 points are covered (more will come with our strong roadmap) :

  1. Full Page Cache
  2. Block Cache
  3. Custom Bloc Cache
  4. Auto Sprite
  5. HTML, JS & CSS minifying & compression
  6. HTaccess fine tuning
  7. CDN auto deploy

Magento Benchmark with Nitrogento

The benchmark context

This said, the main key here is the performance. So what best way than making benchmarks ? Well we tryied almost all of them ! And I’ve to say that there is a lot of benchmarks around !

We installed a basic demostore on http://demostore.nitrogento.com and did the same demostore with Nitrogento on http://nitrostore.nitrogento.com. The server hosting the demo/nitro stores is the very same, actually, it’s even the same machine. The machine was a Quad core 5650 VPS with 8 Go of RAM.

Benchmark used

We choosed to used the following benchmarks, which are considered the most accurate and renowned :

PS : We know some of you love our product but, please, can you consider doing your benchmarks on your own servers, or at least not to often on ours, because recently we had a lot of people benching both sites (http://nitrostore.nitrogento.com and http://demostore.nitrogento.com).

The benchmark issues to be considered

Some tests gave a false results for two reasons :

- First, the  server is located in France. So when you use GTmetrix (for exemple) the test server is located in the US. This means that we have a bit of lag between the test machine and the target machine. One in the other, this is not a big issue since only the real load time is false but the comparison stay exact since both Nitro & Demo stores are located in France so they are in the exact same situation.

- We also found a funny problem. Google and Yahoo (and many others) recommand using multiple CNAMES/HOST to host the static files. That way, your browser is able to download a lot of file at the same time and not only 8 by 8 or 12 by 12 (the exact multi thread number is browser dependant). But when you have several CNAMES pointers, this makes several DNS resolutions and … this can be a problem depending on various factors. The precise problem came up with www.wichloadsfaster.com (WLF). By make 5 DNS requests on Nitrostore and only 1 on Demostore, he claimed that Demostore was faster.

Actually this is not true, but the 4 more NS lookup took a bit more time (resolution from US to France) and as WLF only test the core load (don’t take the pictures, CSS, Js again) it found Nitrostore to be slower. So to get realistics results, the WLF test was made with the CDN feature of Nitrogento desactivated, to avoid having more DNS lookup to do than on a basic demostore. In real life, this CDN feature bring you a lot and we recommand it, of course :)

We noted these troubles in the table of results.

(*) stands for « longer time than real since test machine and bench machine are in US and FR »

(**) stands for « desactivated CDN not to compromise results »

Results

www.whichloadsfaster.com (500 runs)
Time (*)
Demostore 327 ms
Nitrostore 134 ms

Nitrostore : 2,4 times faster.

www.gtmetrix.com
Grade Time to full load
Demostore C/C (72/76) 3,15
Nitrostore A/A (96/94) 2,18

Nitrostore : 43% faster
Nitrostore : +20% to yslow/pagespeed tests

www.MageSpeedTest.com (*)
Trans/sec Time / request
Demostore 12,38 1,86
Nitrostore 28 0,55

Nitrostore : 2,2 times more transaction per seconds
Nitrostore : 3,38 times faster per request

Firebug – Network load time
Requests Time (s) Size (Ko)
Demostore 49 2,14 556
Nitrostore 28 1,35 293

Nitrostore : 42% less HTTP resquests
Nitrogento : 37% faster to load
Nitrostore : 40% less bandwidth / transfer

Funkload (home hammering – 200 users)
Page / sec Page time APDEX
Demostore 25 16 s 0,4
Nitrostore 300 0,7s 1
Funkload (Full scenario – 50 users)
Page / sec Page time APDEX
Demostore 35 10 s 0,55
Nitrostore 100 3,5 s 0,65

Under heavy load,
Nitrostore : up to 18 times faster on the homepage and 3 times faster in the full scenario
Nitrostore : up to 12 time more home page served and 3 times more full scenario
Nitrostore : Continuous perfect APDEX on homepage and 15% better APDEX indice (user experience) on complexe scenario

www.webpagetest.org
Document complete Fully Loaded
Load time (**) First Byte (**) Start render Dom Elements Time (**) Requests KBytes In Time (**) Requests KBytes In
Demostore first 5,7 10 s 0,55 332 5,7 50 574 5,7 50 574
Demostore repeat 1,9 10 s 0,55 332 1,9 2 7 1,9 2 7
Nitrostore first 3,6 3,5 s 0,65 318 3,6 29 303 3,6 29 303
Nitrostore repeat 1,5 3,5 s 0,65 318 1,5 4 18 1,5 4 18

Trial version

But you know what ? Test it by yourself, there is a Trial version there : www.nitrogento.com

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

mar 19

Avant toute chose, le Wiki a été mis à jour sur la partie dimensionnement des infrastructures Web. Ca se passe ici, si vous voyez des erreurs, n’hésitez pas à corriger.

Alors, où en est-on sur le front des performances ?

Eh bien si vous avez mis en place les optimisations qui sont recommandées, celles que l’ont vous a expliqué chez Fragento ou ici, celles que l’on va vous exposer dans les prochains posts, bref si vous faites les choses correctement, vous pouvez atteindre de 200 à 800 sessions « Magento connectées » par core (coeur) de vos processeurs récents.

Mais avant de parler des optimisations en elles mêmes, il faut avoir des moyens de comparer, des unités et des repères communs. Je vous propose d’adopter des « S.M.C » comme unité.

S.M.C ?

En premier lieu « Sessions Magento Connectées », qu’est-ce que cela peut bien représenter… ?

Déjà, on va réduire le nom à SMC pour éviter de trimbaler 5 lignes. On peut prendre de nombreux points de repères différents pour estimer la charge : les sessions apache, les Visiteurs Uniques (V.U) journaliers, horaires, le nombre de page vues, etc… Alors pourquoi choisir les SMC ?

Les SMC cela reste un indicateur pertinent car c’est Magento qui mesure cette valeur. Elle peut donc être utilisées dans d’autres contexte, pour faire d’autres calculs mais surtout elle est mesurée partout de la même façon, ce qui est important pour avoir des repères. Comme c’est Magento qui la mesure, on travail tous sur la même valeur.

Comment les récupérer ? Avec une requête SQL en base de données tout simplement :
select count(*) from log_visitor where ADDTIME(utc_timestamp(), -1500) < last_visit_at;

Cela nous donne les sessions ayant eu une activité lors des 15 dernières minutes. C’est très proche de ce que l’on a dans le backoffice. Une dataquery et un script bash plus tard,

On en fait un beau graphique pour les clients dans Cacti ou avec RRD, MRTG etc… :
Graph SMC
Là, par exemple, on voit un mailing. Monté en charge progressive du nombre de SMC pour atteindre les 1200 vers 18H00. Ca se corrèle bien avec le graphique d’utilisation des cores :

Graph Core

On 4 cores utilisés pour 1200, donc 300 utilisateurs par core, en l’occurence ce sont des AMD Shanghai 2374 à 2,3 Ghz. Comme ce sont des quad cores, on utilise un processeur complet. Évidemment on ne peut pas se permettre d’avoir tous les cores à 100% donc les autres processus Linux tournent sur un autre core dédié d’un autre processeur. Coté base de données, ca glandouille gentillement :

Graph core DB
Il faut lire 0,2 core (200 milli). Ceci étant ce site spécifique sollicite peu la base de données donc ce n'est pas représentatif non plus.

Tester les performances, tests de charge & Benchmark !

De nombreux outils existent, qui mesurent différentes choses. En test de charge purs, on a par exemple Load runner, Apache bench, Opensta etc… Coupler tout cela à des analyseurs de code ou de requêtes SQL (comme la console Mysql enterprise par exemple) permet d’optimiser le code mais ce n’est pas le sujet de ce post et Gilles nous fera peut être un petit article là dessus.

Non, ce qui nous intéresse ici, c’est d’évaluer le nombre de SMC que l’on peut servir dans de bonnes conditions avec la plateforme que l’on aura préparé. Pour cela, load runner et Opensta sont de bons outils. Apache bench n’est pas très adapté sincèrement car son test est toujours le même, donc avec la chaine de cache, à la fin de ces 2000 itérations, il vous sort joyeusement 250 000 connectés :)

Opensta permet de définir des scénarii de tests et d’en jouer plusieurs, de front, à suivre, plusieurs fois les mêmes etc… Le soft tourne sous Windows, il est gratuit et opensource. On peut le trouver ici et même s’il n’est plus entretenu, il fonctionne bien et fait le boulot demandé.

Le but ici n’est pas de faire un manuel ou un howto d’opensta mais globalement d’expliquer ce qui représente de bonnes circonstance de tests, tout au moins réaliste. Ce que je fais, en général, c’est que je demande à mes clients, c’est de réaliser entre vingt et trente scénarii classique de surf. On enregistre un très simple de la personne qui vient sur la home et se déconnecte, un autre ou il fait une recherche un autre ou il clique de produit en produit, etc… Le plus le mieux mais également, le plus logique le mieux !

Le scénario de connexion à la home puis déconnexion, on va le jouer 25% du temps, puis celui du parcours de produit 1, le 2 et aussi les recherches. On mixe le tout savamment et on demande à plusieurs scénarii de se jouer sur le site. Trois qui surf, des connexions déconnexions sur la home, deux recherches en même temps etc… A la fin, on regarde les performances affichées par l’interface d’Opensta et celles collectées dans Cacti. On corrèle les graphs, on analyse et on arrive à estimer la charge que peux tenir un système ! En laissant tourner les scénarii un moment, le graph sera réaliste et on saura dire combien de S.M.C peut faire tenir un core standard.

La suite est un jeu d’enfant, on prend le nombre de V.U prévu en pic, on déduit le nombre de S.M.C que l’on doit pouvoir encaisser et on divise par la performance unitaire d’un Core. On sait alors combien de core on doit mettre en place et donc combien de processeurs !

Bon si une bonne âme veut bien écrire un tuto/howto sur Opensta, je passe mon tour pour le moment et je vous laisse juste en compagnie de deux shoots d’écran, le modeler et le commander :

opensta-commander

On définit son scénario dans le modeler ci-dessous, on planifie dans le commander ci-dessus, et on a un autre module qui collecte et affiche les statistiques.

opensta-modeler

Et voila !

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

fév 11

Bonjour à tous,

Ce post va traiter de l’optimisation de l’Opcode APC.
Pour plus d’informations sur APC, ci dessous, un lien de présentation :

http://fr3.php.net/apc

Dans ce document, nous allons aborder quelques points de réglage. Pour ma part, j’estime qu’il procure un gain au niveau du temps d’accès de la page d’accueil de l’ordre de 0,15s (0,40s vs 0,25s), le tuning a amélioré le temps de réponse de 0.05s. En charge, je pense que les réglage on permis d’augmenter la charge sur le serveur avec un facteur 3.

Je n’ai pas de statistiques exactes sur ce point car j’ai modifié 4 tables dans la base Mysql pour optimiser les performances et diminuer les points de blocage.

Les modifications combinées ont permis de diminuer la charge CPU par 10. (avant les modifications, un test de charge de 200 utilisateurs a fait monter la charge CPU à 100. Le même test de charge avec les réglages que je vais présenter et le changement de 4 tables du type MyISAM au type innodb n’a fait monter la charge CPU qu’à 10).

Tout d’abord, je tiens à préciser que je n’ai rien inventé, j’ai effectué quelques recherche et j’ai ensuite testé.

La référence de mon étude se base sur cet article : http://julien-pauli.developpez.com/tutoriels/php/apc/

La première chose que j’ai faite est la mise à disposition de la page apc.php fournie dans le package pecl d’installation. Cette page php permet d’effectuer un diagnostic de l’état d’APC, notamment de savoir comment il est utilisé.

Par défaut, la taille du cache est de 30Mo, ce qui semble suffisant pour la majorité des applications. De mon coté, j’ai estimé qu’il n’était pas suffisant car j’ai la mémoire utilisée à 95%, voir un peu plus et une très forte fragmentation. La fragmentation est un signe qui m’a indiqué que des fichiers sont régulièrement sortis du cache pour en mettre d’autres. L’autre paramètre qui m’a indiqué que des fichiers n’étaient pas cachés est la statistique « hit and misses », cette statistique etati à 50% de hit. Le simple fait d’augmenter la taille du cache a résolu la fragmentation et mes statistiques de hit & misses sont maintenant proche de 100% de hit (900000 hits vs 300 misses).

J’ai continué mes recherches en parcourant l’article ci dessus et j’ai testé quelques réglages conseillés :
apc.num_files_hint
apc.user_entries_hint
Ci dessous, les réglages spécifiques que j’ai apportés :
apc.shm_size = 128
apc.stat = Off
apc.include_once_override = 1
apc.num_files_hint = 0
apc.user_entries_hint = 0
apc.max_file_size = 2M

Toutes ces fonctions sont détaillés dans la documentation php :
http://fr3.php.net/manual/fr/apc.configuration.php

écrit par Gilles \\ tags: , , ,