20
Juin 11

Hébergement web – CMS – La performance des accès disques

Comme déjà abordé lors d’un précédent article, il est important de ne pas négliger la performance des accès disques (I/O) lorsque l’on fait de l’hébergement, et notamment pour des CMS et bases de données fortement sollicités (ex: eZ Publish / Drupal).

 

C’est dans ce sens que, pour notre plateforme d’hébergement, j’ai fait le choix d’un stockage SAN (FC 8Gbps) permettant de répondre à ces besoins. Certes, cela a un coût non négligeable, mais les résultats sont la…

 

Nombre de sites internet eZ Publish qui souffraient de performances anormales, se sont vus offrir une deuxième vie lors de leur migration sur « la baie » (nom donné par mes chers collaborateurs :p).

Bon, est-ce que c’était normal qu’ils aient autant de problèmes? Certainement que non, mais bon, ca diminue fortement les temps de maintenance :p

 

Mais voila.. parfois, le discours client, des commerciaux, voir même des chefs de projet, est très accès sur le prix et ils ont la terrible manie de comparer une offre hébergement « spécialisée » , avec les offres dites « grand public » que l’on trouve ici ou la.

 

C’est pour cela que je me suis dit… voyons voyons, faisons quelques comparaisons, ne serait-ce que sur les performances I/O.

Ainsi, j’ai exécuté un petit shell (voir ci dessous) qui effectue des créations de fichiers sur un laps de temps, sur 3 hôtes différents:

  • une VM GANDI de test (1 part / 1 CPU / 2Go RAM / 20G disque dur – SAS raid 60)
  • un serveur KIMSUFI OVH (1 CPU dualCore / 2Go RAM/ 250G disque dur – SATA DAS)
  • une VM de « chez moi » (1 vCPU / 2 Go RAM/ 20 Go disque dur – FC raid 6)

 

Vous l’avez deviné, ici peu importe la taille du disque.

Histoire de ne pas être trop long, je me suis contenté de le lancer que sur 30 secondes…. le résultat est criant.

Nombre de fichiers créés en 30 secondes

Nombre de fichiers créés en 30 secondes

root@hostname:~# sh bench_create.sh 30 /home/

 

GANDI:

835 files created in 30 seconds.
860 files created in 30 seconds.
840 files created in 30 seconds.
822 files created in 30 seconds.

OVH / KIMSUFI:

210 files created in 30 seconds.
214 files created in 30 seconds.
194 files created in 30 seconds.
225 files created in 30 seconds.

VM « maison »:

1399 files created in 30 seconds.
1340 files created in 30 seconds.
1635 files created in 30 seconds.
1744 files created in 30 seconds.

Bench creation fichiers: OVH vs GANDI vs VM Maison

Comme on peut le voir, il y a un grand écart entre les 3 environnements testés.

 

Au final, la VM GANDI s’en sort plutôt bien comparé au KIMSUFI d’OVH (à prix équivalent ~ 50 € / mois)

 

Mais quand on veut des garanties, des services et des performances un peu plus haut de gamme, il est bon de convenir que ces offres ne sont plus adéquates.

 

Après on est d’accord, si c’est pour héberger votre blog personnel, ces deux fournisseurs sont ce qu’il vous faut 🙂

 

#!/bin/sh
#### script bench_create_file.sh
HOSTNAME=`hostname`
TIMEOUT=$1
BASEDIR=$2
PID=$$

TIMESTART=`date '+%s'`
TIMEEND=`expr $TIMESTART + $TIMEOUT`

FILECNT=0
RCNT=1
while [ 1 ]; do
       ROOTPATH=${BASEDIR}/${HOSTNAME}_${PID}_${RCNT}
       mkdir $ROOTPATH

       DCNT=1
       while [ $DCNT -le 100 ]; do
               DIRPATH=${ROOTPATH}/dir_${DCNT}
               mkdir $DIRPATH

               FCNT=1
               while [ $FCNT -le 100 ]; do
                       FILEPATH=${DIRPATH}/file_${FCNT}.bin
                       dd if=/dev/zero of=$FILEPATH bs=65536 count=16 &> /dev/null
                       sync
                       echo -n "."
                       let FILECNT=FILECNT+1
                       let FCNT=FCNT+1

                       TIMENOW=`date '+%s'`
                       if [ $TIMENOW -ge $TIMEEND ]; then
                               echo "PID $PID : $FILECNT files created in $[$TIMENOW - $TIMESTART] seconds."
                               exit
                       fi
               done
               echo ""
               let DCNT=DCNT+1
       done
       let RCNT=RCNT+1
done

  • Interessant!
    Est-ce tu pourrais refaire ton script en php? Ce serait plus loin « du metal », mais plus près des applis web réelles. Quoique je ne crois pas qu’il y ait une grosse différence dans les résultats…

  • Moi pas parler PHP, Moi parler bash :p

  • Je crois qu’il y a un point à ne pas négliger ; chez OVH avec kimsufi non virtuel, tu as un disque dur rien que pour toi, alors que chez Gandi, le stockage c’est du très gros modèle, très efficace mais également très partagé…

    Cela implique que sur un disque de kimsufi, tu n’as pas de phénomène de moment creux et d’heures de pointes, tandis que chez Gandi, tu as ce risque.

    Pour que les VPS gandi puissent avoir des performances respectables dans les pires heures de pointes, il faut que le système soit surdimensionné pour les moments creux, et donc si tu es presque le seul à tirer fortement dessus, la perfermonce est excellente.

    As-tu essayé de voir la variabilité des performances chez Gandi en fonction de l’heure de la journée ?

  • salut David D. 😉

    oui, j’ai effectué le test en après midi et le soir.

    Ta description est juste, mais je vois d’autres avantages au SAN/NAS partagé: la sécurité et la gestion centralisé, et ceux, coté sysadmin.

    Il est plus facile de surveiller et garantir la performance d’un gros système de stockage, que des milliers de disques sur chaque serveur.

    Mais je te rejoins, il faut comparer ce qui est comparable.

    Ici, à une certaine tarification, qui est l’élément premier de comparaison, je n’ai pas du tout le même service rendu.

    Apres, il n’y a aucune garantie chez Gandi de servir tjours la même qualité, c’est sur…

  • Question variabilité chez Gandi, seul le disque me laisse perplexe (bien qu’il soit probable que la performance minimum, hors exception, soit respectable).

    Le reste c’est quand même du Xen, avec ressources bien garanties, ce qu’on ne retrouve pas chez pas mal de concurrents en VPS.

    Le seul truc que je reproche vraiment à Gandi, c’est la bande passante attribuée par part : si ça ne concernait que le traffic sortant vers Internet, ça irait, mais dans l’état actuel ça incite à ne pas distribuer sur plusieurs VPS afin de ne pas consommer de la bande passante pour des communications entre différents VPS de la même infrastructure. Le problème leur a déjà été soulevé : http://lacuisinedegandi.net/post/2011/07/08/Penser-architecture-web-Aller-plus-loin-avec-plusieurs-centres-de-donnees#c183115

    Pour la fiabilité et la supervision, c’est sûr que c’est plus rationalisé quand ça se fait sur une grande échelle. Après faut voir aussi si l’on est prêt à prendre le risque d’un peu d’indisponibilité (le temps qu’une panne matérielle soit gérée et que les backups soit rétablis) ou si l’on préfère vraiment une solution qui dès le départ garantit une très forte disponibilité. Et c’est sûr que de ce point de vue, la solution de Gandi semble intéressante.

  • Ah mais tout a fait!

    Apres, il faut rester réaliste: ces offres ne sont pas faites pour répondre à des besoins de HA et performance.

    Et c’est l’objet du post… ces offres sont super pour des besoins perso, voir des petits projets « pro ».

    C’est la qu’il y a une confusion dans la tête des gens!
    Il faut rester honnête avec soi même : pas cher… c’est pas cher :p

    Je vais acheter une pioche à 8€ chez Jardiland… c’est parfait pour retourner mon jardin de 18m². Demain, si j’en ai 100… je vais réfléchir autrement 😉