Mes permiers tests de virtualisation datent de 1999, époque à laquelle VMware sortait son fameux « VMware Workstation », logiciel userland de virtualisation logicielle qui permettait à tout un chacun de goûter aux joies de la virtualisation, technologie pourtant bien connue des mainframes IBM depuis les années 70.
En 12 ans, de nombreux travaux on été menés autour de ce sujet, et si VMware a toujours pignon sur rue, d’autres technologies de virtualisation très performantes ont vu le jour, parmi elles citons KVM, ou encore Xen.

NBS-System utilise Xen intensivement depuis maintenant un an dans son offre de serveur privé virtuel, et le gain en temps d’administration nous a poussé à considérer l’utilisation massive de Xen, même pour les serveurs dédiés, sauf demande expresse du client. Quel intérêt me direz-vous ? Plusieurs vous répondrai-je. Imaginez pas exemple l’aisance du basculement d’un serveur à l’autre, la migration à chaud, le boot diskless, les snapshots d’environnements complets, l’ajout / diminution de ressources à chaud, l’ajout de nouvelles instances de developpement, et j’en passe.

À cet instant, tout le monde se pose la même question: Oui mais… et les perfs !
Judicieuse et légitime question. On peut lire à peu près tout et n’importe quoi sur la virtualisation, et très souvent les commentaires des « spécialistes » se fondent sur des on-dit. Les rapports les plus serieux parlent de 3 à 7% de perte de performance entre une machine réelle et son équivalent virtuel, mais dans notre cas de figure (hébergement d’applicatifs PHP/MySQL lourds), cette échelle s’applique-t-elle de la même façon ?
C’est ce que nous avons souhaité valider.

Pour la réalisation de ce benchmark naïf, nous disposons d’une machine de belle facture :

  • Deux processeurs hexacore Intel x5650
  • 24Go de Mémoire vive DDR3
  • 300Go de disque SAS en RAID 1

Le benchmark se déroule en deux étapes :

  • Un premier test de charge réalisé sur la machine « bare métal », une machine Debian GNU/Linux stable 64 bits munie d’un noyau 2.6.27 Grsec
  • Le même test de charge sur la même machine, mais sur un domU paravirtualisé auquel on affectera tous les cores de la machine, et pratiquement toute sa mémoire vive.

Les applicatifs soumis à la charge sont bien evidemment Apache (2.2 Prefork) et MySQL 5, qui servent un Magento 1.4 (volontairement) faiblement customisé.

Voici le résultat du premier test sur la machine physique :

On constate une moyenne de 138 pages par seconde pour un nombre croissant d’utilisateurs simultanés, effectuant donc des actions au même instant. Lors de ce test, de 20 à 180 utilisateurs virtuels déploient un scenario en boucle.
On voit très clairement que pendant toute la durée du test, l’indice Apdex reste en status « Excellent ».
À 180 utilisateurs simultanés, la moitié des pages renvoient des codes 500 car la base de données MySQL ne peut plus suivre le nombre de requêtes que provoque le total de 5000 pages demandées.

Interessons-nous maintenant au temps de réponse moyen des pages pendant la durée de ce test

Avec un pic à 0.7 secondes, on comprend les résultats de l’Apdex puisque nous restons toujours en dessous de la seconde. Ces résultats sont parfaitement cohérents avec les précédents benchmarks que nous avons pu mener, rien de surprenant

Passons maintenant à la phase 2 de notre test, et analysons les résultats de notre attaque sur une machine virtuelle Xen paravirtualisée bénéficiant de caractéristiques similaires à la machine physique qui la supporte :

Avec une moyenne de 133 pages par secondes, c’est une des légende les plus tenaces de l’IT qui fait grise mine: à périmètre équivalent, les résultats sont sensiblement identiques, c’est un differenciel moyen de 3.5% que nous notons entre les deux tests de charge. L’indice Apdex affiche fièrement de l' »Excellent » à tous les étages et le nombre d’erreurs générées, la encore en conséquence de l’écroulement de MySQL, est similaire au test sur machine physique.

Du coté du temps de réponse moyen, le résultat est encore plus éloquent :

On pourrait pratiquement superposer ce graphe à celui généré sur l’architecture réelle tant les résultats sont proches. Notons que sur ce graphe, et nous l’avons reproduit plusieurs fois, l’écart type est beaucoup plus faible que dans le scénario 1, garantissant une plus grande predictibilité.

Ces résultats sont reproductibles par tout un chacun, et aucune attention particulière n’a été portée aux DomUs par rapport au scénario physique.

Forts de ces conclusions, mais évidemment de bien d’autres stress-tests et du succès de l’offre serveur privé virtuel, nous avons naturellement franchi une nouvelle étape dans le mouvement d’industrialisation de masse de nos plateformes.

Emile Heitor
Emile Heitor
Après avoir été CTO de NBS System, Émile conseille désormais nos clients sur leurs projets les plus complexes, notamment sur le Cloud public AWS. Expert reconnu dans le milieu informatique, toujours à la pointe des nouvelles technologies, il sait comprendre et faire comprendre les enjeux et les évolutions du marché IT.