Quel est le coût d’exécution d’un conteneur Docker

Voici un excellent document de recherche IBM de 2014 intitulé “Une comparaison actualisée des performances des machines virtuelles et des conteneurs Linux” par Felter et al. qui fournit une comparaison entre les conteneurs bare metal, KVM et Docker. Le résultat général est que Docker est presque identique aux performances natives et plus rapide que KVM dans toutes les catégories.

L’exception à cette règle est le NAT de Docker – si vous utilisez le mappage de port (par exemple, Docker, docker run -p 8080:8080 ), vous pouvez vous attendre à un léger impact de latence, comme indiqué ci-dessous. Cependant, vous pouvez maintenant utiliser la stack du réseau hôte (par exemple docker run --net=host ) lors du lancement d’un conteneur Docker, qui fonctionnera de manière identique à la colonne Native (comme indiqué dans les résultats de latence Redis).

Ils ont également effectué des tests de latence sur quelques services spécifiques, tels que Redis. Vous pouvez voir qu’au-dessus de 20 threads client, la surcharge de latence la plus élevée devient Docker NAT, puis KVM, puis un lien approximatif pour l’hôte / natif Docker.

Juste parce que c’est un document vraiment utile, voici d’autres chiffres. Veuillez le télécharger pour un access complet.

Jetez un oeil à Disk IO:

Maintenant, en regardant les frais généraux du processeur:

Maintenant, quelques exemples de mémoire (lisez le papier pour plus de détails, la mémoire peut être très compliquée)

Docker n’est pas la virtualisation en tant que telle – au lieu de cela, c’est une abstraction en plus du support du kernel pour différents espaces de noms de processus, espaces de noms de périphériques, etc. Un espace de noms n’est pas insortingnsèquement plus cher ou inefficace qu’un autre, alors ce qui fait que Docker a un impact sur les performances dépend de ce qui se trouve réellement dans ces espaces de noms.

Les choix de Docker en termes de configuration des espaces de noms pour ses conteneurs ont des coûts, mais ces coûts sont tous directement associés aux avantages – vous pouvez les abandonner, mais vous renoncez également aux avantages associés:

• Les systèmes de fichiers en couches sont chers – exactement ce que les coûts varient avec chacun (et Docker prend en charge plusieurs moteurs), et avec vos modèles d’utilisation (fusionner plusieurs répertoires volumineux ou fusionner un ensemble de systèmes de fichiers très volumineux), ne sont pas libres D’autre part, une grande partie des fonctionnalités de Docker – être capable de créer des invités à partir d’autres invités d’une manière conforme à celle de l’écriture et d’obtenir les avantages du stockage implicites dans le même système – revient à payer ce coût.
• DNAT coûte cher à l’échelle, mais vous permet de configurer le réseau de vos invités indépendamment de celui de votre hôte et de disposer d’une interface pratique pour transférer uniquement les ports de votre choix. Vous pouvez remplacer cela par un pont vers une interface physique, mais encore une fois, perdez les avantages.
• Pouvoir exécuter chaque stack de logiciel avec ses dépendances installées de la manière la plus pratique – indépendamment de la dissortingbution de l’hôte, de libc et des autres versions de bibliothèque – est un avantage considérable, mais vous devez charger plusieurs fois les bibliothèques partagées (lorsque leurs versions différer) a le coût que vous attendez.

Et ainsi de suite. L’impact de ces coûts sur votre environnement – avec vos schémas d’access au réseau, vos contraintes de mémoire, etc. – est un élément pour lequel il est difficile de fournir une réponse générique.

Voici quelques autres tests pour le Docker based memcached server host native memcached server utilisant l’outil de test Twemperf https://github.com/twitter/twemperf avec 5000 connexions et un taux de connexion de 20k

La surcharge de temps de connexion pour memcached basé sur docker semble être en accord avec le livre blanc ci-dessus à une vitesse approximativement deux fois plus élevée.

Twemperf Docker Memcached

 Connection rate: 9817.9 conn/s Connection time [ms]: avg 341.1 min 73.7 max 396.2 stddev 52.11 Connect time [ms]: avg 55.0 min 1.1 max 103.1 stddev 28.14 Request rate: 83942.7 req/s (0.0 ms/req) Request size [B]: avg 129.0 min 129.0 max 129.0 stddev 0.00 Response rate: 83942.7 rsp/s (0.0 ms/rsp) Response size [B]: avg 8.0 min 8.0 max 8.0 stddev 0.00 Response time [ms]: avg 28.6 min 1.2 max 65.0 stddev 0.01 Response time [ms]: p25 24.0 p50 27.0 p75 29.0 Response time [ms]: p95 58.0 p99 62.0 p999 65.0 

Twemperf Centmin Mod Memcached

 Connection rate: 11419.3 conn/s Connection time [ms]: avg 200.5 min 0.6 max 263.2 stddev 73.85 Connect time [ms]: avg 26.2 min 0.0 max 53.5 stddev 14.59 Request rate: 114192.6 req/s (0.0 ms/req) Request size [B]: avg 129.0 min 129.0 max 129.0 stddev 0.00 Response rate: 114192.6 rsp/s (0.0 ms/rsp) Response size [B]: avg 8.0 min 8.0 max 8.0 stddev 0.00 Response time [ms]: avg 17.4 min 0.0 max 28.8 stddev 0.01 Response time [ms]: p25 12.0 p50 20.0 p75 23.0 Response time [ms]: p95 28.0 p99 28.0 p999 29.0 

Voici les bencmarks utilisant l’outil de test memtier

memtier_benchmark docker Memcached

 4 Threads 50 Connections per thread 10000 Requests per thread Type Ops/sec Hits/sec Misses/sec Latency KB/sec ------------------------------------------------------------------------ Sets 16821.99 --- --- 1.12600 2271.79 Gets 168035.07 159636.00 8399.07 1.12000 23884.00 Totals 184857.06 159636.00 8399.07 1.12100 26155.79 

memtier_benchmark Centmin Mod Memcached

 4 Threads 50 Connections per thread 10000 Requests per thread Type Ops/sec Hits/sec Misses/sec Latency KB/sec ------------------------------------------------------------------------ Sets 28468.13 --- --- 0.62300 3844.59 Gets 284368.51 266547.14 17821.36 0.62200 39964.31 Totals 312836.64 266547.14 17821.36 0.62200 43808.90