Récemment, j’ai pu mettre la main sur une nouvelle machine de test dotée d’un Xeon Ivy Bridge. J’ai donc pu à nouveau tester les performances CPU de Docker et KVM. Bonne nouvelle, j’ai pu reproduire les précédents résultats.
Introduction
Précédemment, j’ai mené un projet pour l’école consistant à comparer les performances CPU de Docker et de KVM. Nous nous sommes basés principalement sur l’article “An Updated Performance Comparison of Virtual Machines and Linux Containers”, écrit par une équipe d’IBM Research.
J’ai réussi à trouver une machine de test pour pas cher sur internet, je peux donc à nouveau procéder à quelques tests de performance. Pour commencer j’ai essayé de reproduire les résultats que nous avons trouvés précédemment, à savoir, un écart de performance de moins de 1% entre machine native, conteneur Docker et KVM.
Typologie de la machine
la machine utilisée lors du test est un Dell Poweredge T110 II. Il est équipé d’un Intel Xeon E3-1220 v2 avec 4 cœurs à 3.1 GHz, Turbo Boost 2.0 à 3.5 GHz et 8 Mo de cache. Côté grand public, ça correspond à un i5 3450. Le contrôleur mémoire a deux canaux et permet d’utiliser de la DDR3 1600 ECC, la machine en est équipée de 16 Go. Concernant les jeux d’instructions pour la virtualisation, tous sont présents : VT-x, EPT et VT-d. Malheureusement, l’hyperthreading n’est pas de la partie, mais pour des tests de performance c’est mieux. La machine est aussi équippée d’une carte RAID PERC H200 en SAS 6Gbit/s. Côté disque dur, il y a un unique Seagate Cheetah de 300 Go en 15K tours par minutes.
Changements dans le protocole
Tout d’abord, un petit rappel du protocole utilisé. Pour tester les performances CPU nous utilisons une compression multithread sur un fichier de 100 Mo. Nous répétons le test plusieurs fois en enregistrant le temps. Enfin, nous calculons le débit de compression moyen obtenu.
Cependant, par rapport à notre ancien protocole, quelques changements ont été apportés. Je trouve qu’Arch Linux, bien qu’il soit possible de le paramétrer très finement, demande beaucoup de temps pour être administré. De plus, je connais mieux Debian et ses dérivés. Dans ce test j’utilise donc Ubuntu Server 16.04 qui ressemble beaucoup à Debian tout en ayant de base un noyau et des paquets plus récents. Plutôt que de faire 500 tests durant toute une nuit, je n’ai lancé que 10 répétitions. Statistiquement les 10 répétitions suffisent pour conclure puisque l’écart type est très faible.
Concernant la configuration de la machine virtuelle, celle-ci est dotée de 4 cœurs et de 8 Go de RAM. L’architecture du processeur est configurée en mode IvyBridge. Les drivers du disque et de la carte réseau sont tous les deux de type VirtIO. Je n’ai pas enlevé de périphériques inutiles, par exemple la machine virtuelle a une carte son, un serveur SPICE et d’autres périphériques qui ne sont pas essentiels pour le test de performance.
Concernant les versions des logiciels, le noyau d’Ubuntu est le 4.4.0-24-generic x86_64, QEMU est en version 2.5.0 et Docker est en version 1.11.2, build b9f10c9.
Résultats
Pour chaque configuration, nous mesurons la moyenne et l’écart-type des 10 tests réalisés.
Natif (Ubuntu kernel 4.4.0) | Docker (Ubuntu) | KVM (Ubuntu kernel 4.4.0) | ||
---|---|---|---|---|
Réel | Moyenne (s) | 17.49 | 17.48 | 17.68 |
Ecart-type (s) | 0.03 | 0.03 | 0.04 | |
User | Moyenne (s) | 69.18 | 69.18 | 69.94 |
Ecart-type (s) | 0.08 | 0.05 | 0.07 | |
System | Moyenne (s) | 0.10 | 0.10 | 0.11 |
Ecart-type (s) | 0.02 | 0.02 | 0.02 |
Les variances étant très petites et le nombre de tests grand, la comparaison directe des moyennes est donc significative. Si on modélise le temps de calcul par une loi normale, les intervalles de confiance de la moyenne à environ 99.7% sont les suivants :
Borne basse l’IC de la moyenne | Borne haute de l’IC de la moyenne | |
---|---|---|
Natif (Ubuntu kernel 4.4.0) | 17.45 | 17.52 |
Docker (Ubuntu) | 17.44 | 17.52 |
KVM (Ubuntu kernel 4.4.0) | 17.63 | 17.74 |
Concernant le débit de compression du fichier en Mo/s :
Moyenne (Mo/s) | Ecart au natif | |
---|---|---|
Natif (Ubuntu kernel 4.4.0) | 5.72 | 0.00 % |
Docker (Ubuntu) | 5.72 | -0.04 % |
KVM (Ubuntu kernel 4.4.0) | 5.66 | 1.10 % |
Ces résultats correspondent à ceux que nous avons trouvés précédemment. L’écart de performance CPU introduit par Docker n’est pas significatif, on ne peut pas conclure qu’il est plus lent que la machine native. Concernant KVM, les résultats sont différents dans le sens où on obtient cette fois une différence significative. On peut donc conclure que KVM est significativement plus lent que la machine native. Cette différence de performance est toutefois contenue puisqu’elle est de 1,1%.
Discussion
Le benchmark est ciblé sur une charge CPU très particulière. Par la suite, je vais essayer d’élargir le champ des types de charges pour avoir plus de recul quant aux performances CPU.
Le TurboBoost du processeur peut faire une différence dans le cas de tests de performance. En effet, cette fonctionnalité modifie la fréquence du CPU en fonction de la charge sur celui-ci. Or la modification de la fréquence a une incidence directe sur les performances puisque plus d’instructions par secondes sont exécutées. Dans mon cas, je pense que le TurboBoost n’a pas eu beaucoup d’incidence sur le résultat. En effet les tests ont été lancés dans les mêmes conditions et ont durés le même temps, on peut donc supposer que le TurboBoost s’est comporté de la même manière dans tous les cas.
Conclusion
Sur une distribution Ubuntu Server 16.04 dotée du noyau 4.4, avec une installation de base de Docker et de KVM, sans optimisations particulières, lors d’une compression sur plusieurs cœurs, nous n’obtenons pas de différence significative entre les performances de la machine native et de Docker. La machine virtuelle KVM est significativement plus lente d’environ 1%.
Pour en savoir plus
- Wes Felter, Alexandre Ferreira, Ram Rajamony, Juan Rubio. An Updated Performance Comparison of Virtual Machines and Linux Containers [en ligne]. Lien vers l’article d’IBM Research.
- Luc Forget, Mathieu Gaillard. Comparaison des performances CPU : Docker contre KVM [en ligne]. Lien vers notre précédent article.