Was ist die Laufzeitleistungs-Kosten eines Docker-Container?

Question

Ich würde gerne die Laufzeitleistungskosten eines Docker-Containers umfassend verstehen. Ich habe Referenzen dazu gefunden, dass die Netzwerkleistung laut Anekdoten etwa ~100 µs langsamer ist.

Ich habe auch Referenzen dazu gefunden, dass die Laufzeitkosten als "vernachlässigbar" und "nah bei null" bezeichnet werden, aber ich würde gerne genauer wissen, was diese Kosten sind. Ideal wäre es, zu wissen, was Docker mit einem Leistungspreis abstrahiert und welche Dinge ohne Leistungspreis abstrahiert sind. Networking, CPU, Speicher usw.

Darüber hinaus, wenn es Abstraktionskosten gibt, gibt es Möglichkeiten, die Abstraktionskosten zu umgehen. Zum Beispiel könnte ich möglicherweise eine Festplatte direkt gegenüber virtuell in Docker einbinden.

Answer 1

Eine ausgezeichnete IBM-Forschungspapier von 2014 "An Updated Performance Comparison of Virtual Machines and Linux Containers" von Felter et al. bietet einen Vergleich zwischen Bare-Metal, KVM und Docker-Containern. Das allgemeine Ergebnis lautet: Docker ist praktisch identisch mit der nativen Leistung und schneller als KVM in jeder Kategorie.

Die Ausnahme hiervon ist das NAT von Docker - wenn Sie Port-Mapping verwenden (z.B. docker run -p 8080:8080), dann können Sie eine geringfügige Latenz bemerken, wie unten gezeigt. Jedoch können Sie jetzt den Host-Netzwerk-Stack verwenden (z.B. docker run --net=host), wenn Sie einen Docker-Container starten, der identisch mit der nativen Spalte funktionieren wird (wie in den weiter unten gezeigten Redis-Latenzresultaten).

Sie führten auch Latenztests an ein paar spezifischen Diensten durch, wie Redis. Sie können sehen, dass bei über 20 Client-Threads die höchste Latenz bei Docker NAT auftritt, dann bei KVM, und dann ein grobes Gleichgewicht zwischen Docker-Host/Native.

Nur weil es ein wirklich nützliches Papier ist, hier sind einige andere Zahlen. Bitte laden Sie es herunter, um vollen Zugriff zu erhalten.

Einen Blick auf die Festplatten-E/A werfen:

Nun betrachten wir die CPU-Überlastung:

Jetzt einige Beispiele für den Speicher (lesen Sie das Papier für Details, Speicher kann extra knifflig sein):

Answer 2

Docker ist keine Virtualisierung im eigentlichen Sinne - stattdessen handelt es sich um eine Abstraktion auf die Unterstützung des Kernels für verschiedene Prozess-Namespaces, Geräte-Namespaces usw.; ein Namespace ist nicht intrinsisch teurer oder ineffizienter als ein anderer, also worin Docker tatsächlich eine Leistungssteigerung hat, hängt davon ab, was sich tatsächlich in diesen Namespaces befindet.

---

Dockers Entscheidungen hinsichtlich der Konfiguration von Namespaces für seine Container haben Kosten, aber diese Kosten sind alle direkt mit Vorteilen verbunden - Sie können darauf verzichten, aber damit geben Sie auch den damit verbundenen Nutzen auf:

• Schichtdateisysteme sind teuer - genau welche Kosten damit verbunden sind, variiert bei jedem (und Docker unterstützt mehrere Backend), und mit Ihren Nutzungs-Mustern (das Zusammenführen mehrerer großer Verzeichnisse oder das Zusammenführen eines sehr tiefen Satzes von Dateisystemen kann besonders teuer sein), aber sie sind nicht kostenlos. Andererseits beruht ein Großteil der Funktionalität von Docker darauf, Gäste auf anderen Gästen in einer Copy-on-Write-Weise aufzubauen und die impliziten Speichervorteile dabei zu nutzen - dies bedeutet die Bezahlung dieses Preises.
• DNAT wird bei großem Maßstab teuer - ermöglicht Ihnen jedoch, das Netzwerk Ihres Gastes unabhängig von dem Ihres Hosts zu konfigurieren und eine bequeme Schnittstelle zum Weiterleiten nur der Ports zu haben, die Sie zwischen ihnen möchten. Sie können dies durch eine Brücke zu einem physischen Interface ersetzen, verlieren jedoch erneut den Vorteil.
• Die Möglichkeit, jeden Software-Stack mit seinen Abhängigkeiten auf die bequemste Weise auszuführen - unabhängig von der Distro des Hosts, der libc und anderen Bibliotheks-Versionen - ist ein großer Vorteil, erfordert jedoch mehrfaches Laden von gemeinsam genutzten Bibliotheken (wenn ihre Versionen sich unterscheiden), was die erwarteten Kosten hat.

und so weiter. Inwieweit diese Kosten Sie tatsächlich in Ihrer Umgebung beeinflussen - mit Ihren Zugriffsmustern auf das Netzwerk, Ihren Speicherbeschränkungen usw. - ist eine Frage, für die es schwierig ist, eine generische Antwort zu geben.

Answer 3

Hier sind einige weitere Benchmarks für den Docker-basierten Memcached-Server im Vergleich zum hostinternen Memcached-Server unter Verwendung des Twemperf-Benchmark-Tools https://github.com/twitter/twemperf mit 5000 Verbindungen und einer Verbindungsraten von 20k

Die Verbindungszeitüberschreitungen für Docker-basierten Memcached scheinen mit der oben genannten Whitepaper in etwa doppelter Geschwindigkeit übereinzustimmen.

Twemperf Docker Memcached

Verbindungsrate: 9817,9 Verbindungen/s
Verbindungszeit [ms]: Durchschnitt 341,1 Min 73,7 Max 396,2 Standardabweichung 52,11
Verbindungszeit [ms]: Durchschnitt 55,0 Min 1,1 Max 103,1 Standardabweichung 28,14
Anforderungsrate: 83942,7 Anfragen/s (0,0 ms/Anfrage)
Anforderungsgröße [B]: Durchschnitt 129,0 Min 129,0 Max 129,0 Standardabweichung 0,00
Antwortrate: 83942,7 Antworten/s (0,0 ms/Antwort)
Antwortgröße [B]: Durchschnitt 8,0 Min 8,0 Max 8,0 Standardabweichung 0,00
Antwortzeit [ms]: Durchschnitt 28,6 Min 1,2 Max 65,0 Standardabweichung 0,01
Antwortzeit [ms]: p25 24,0 p50 27,0 p75 29,0
Antwortzeit [ms]: p95 58,0 p99 62,0 p999 65,0

Twemperf Centmin Mod Memcached

Verbindungsrate: 11419,3 Verbindungen/s
Verbindungszeit [ms]: Durchschnitt 200,5 Min 0,6 Max 263,2 Standardabweichung 73,85
Verbindungszeit [ms]: Durchschnitt 26,2 Min 0,0 Max 53,5 Standardabweichung 14,59
Anforderungsrate: 114192,6 Anfragen/s (0,0 ms/Anfrage)
Anforderungsgröße [B]: Durchschnitt 129,0 Min 129,0 Max 129,0 Standardabweichung 0,00
Antwortrate: 114192,6 Antworten/s (0,0 ms/Antwort)
Antwortgröße [B]: Durchschnitt 8,0 Min 8,0 Max 8,0 Standardabweichung 0,00
Antwortzeit [ms]: Durchschnitt 17,4 Min 0,0 Max 28,8 Standardabweichung 0,01
Antwortzeit [ms]: p25 12,0 p50 20,0 p75 23,0
Antwortzeit [ms]: p95 28,0 p99 28,0 p999 29,0

Hier sind Benchmarks mit dem Memtier-Benchmark-Tool

memtier_benchmark Docker Memcached

4         Threads
50        Verbindungen pro Thread
10000     Anfragen pro Thread
Typ        Ops/Sek     Treffer/Sek   Misses/Sek      Latenz       KB/Sek
------------------------------------------------------------------------
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        Verbindungen pro Thread
10000     Anfragen pro Thread
Typ        Ops/Sek     Treffer/Sek   Misses/Sek      Latenz       KB/Sek
------------------------------------------------------------------------
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

Answer 4

Vergleich von Laufzeitbibliotheken

Ich werde die Frage nach den Ausführungsleistungskosten eines Containers im Hinblick auf Laufzeitbibliotheken ansprechen.

Geschwindigkeit: Musl vs. glibc

In den Alpine Linux-Containern werden die Laufzeitbibliotheken von Musl anstelle von glibc bereitgestellt, und laut dem unten stehenden Link kann es einen Leistungsunterschied zwischen den beiden geben:

https://www.etalabs.net/compare_libcs.html

Ich habe verschiedene Meinungen zu diesem Thema gelesen, die besagen, dass Musl aufgrund seiner geringen Größe und seiner deutlich moderneren Struktur auch ein höheres Maß an Sicherheit gegenüber glibc bietet. Bisher konnte ich jedoch keine Daten finden, die diese Ansichten unterstützen.

Kompatibilität

Auch wenn Musl schneller und sicherer ist, kann es jedoch Kompatibilitätsprobleme aufwerfen, da Musl sich wesentlich von glibc unterscheidet. Ich stelle jedoch fest, dass bei der Erstellung eines Docker-Images mit apk zur Installation meiner Pakete natürlich keine Kompatibilitätsprobleme auftreten.

Schlussfolgerung

Wenn die Leistung wichtig ist, erstellen Sie (2) Container, wobei einer Alpine Linux mit Musl und ein anderer mit einer Distribution, die glibc verwendet, und führen Sie einen Benchmark durch. Und natürlich teilen Sie Ihre Ergebnisse in den Kommentaren mit!!!!