Docker 容器的运行时性能成本是多少？

Question

我想全面了解 Docker 容器的运行时性能成本。 我发现有关网络的参考资料慢了 ~100µs 。

我还发现提到运行时成本“可以忽略不计”和“接近于零”，但我想更准确地知道这些成本是多少。 理想情况下，我想知道 Docker 是用性能成本抽象的什么，以及在没有性能成本的情况下抽象的东西。 网络、CPU、memory等

此外，如果存在抽象成本，是否有办法绕过抽象成本。 例如，也许我可以在 Docker 中直接挂载磁盘而不是虚拟挂载磁盘。

Answer 1

Felter 等人 2014 年出色的 IBM 研究论文“ 虚拟机和 Linux 容器的更新性能比较”。 提供了裸机、KVM 和 Docker 容器之间的比较。 总体结果是： Docker 几乎与本机性能相同，并且在每个类别中都比 KVM 更快。

Docker 的 NAT 是个例外——如果您使用端口映射（例如， docker run -p 8080:8080 ），那么您可以预期延迟会受到轻微影响，如下所示。 但是，您现在可以在启动 Docker 容器时使用主机网络堆栈（例如docker run --net=host ），这将与 Native 列的性能相同（如下面的 Redis 延迟结果所示）。

他们还对一些特定服务（例如 Redis）进行了延迟测试。 您可以看到超过 20 个客户端线程，最高延迟开销是 Docker NAT，然后是 KVM，然后是 Docker 主机/本机之间的粗略联系。

仅仅因为它是一篇非常有用的论文，这里有一些其他的数字。 请下载以获取完整访问权限。

查看磁盘 I/O：

现在看看 CPU 开销：

现在一些内存示例（阅读论文了解详细信息，内存可能会更加棘手）：

Answer 2

Docker 本身并不是虚拟化——相反，它是内核对不同进程命名空间、设备命名空间等的支持之上的抽象； 一个命名空间本质上并不比另一个更昂贵或低效，因此实际上使 Docker 对性能产生影响的是这些命名空间中实际存在的内容。

---

Docker 在如何为其容器配置命名空间方面的选择是有成本的，但这些成本都与收益直接相关——你可以放弃它们，但这样做你也放弃了相关的收益：

• 分层文件系统很昂贵——确切地说，成本因每个人而异（Docker 支持多个后端），以及您的使用模式（合并多个大目录，或合并一组非常深的文件系统将特别昂贵），但它们不是免费的。 另一方面，Docker 的大量功能——能够以写时复制的方式从其他来宾构建来宾，并获得同样隐含的存储优势——靠支付这笔费用。
• DNAT 在规模上变得昂贵——但为您提供了能够独立于主机配置来宾网络的好处，并且有一个方便的接口来仅在它们之间转发您想要的端口。 您可以将其替换为连接到物理接口的桥接器，但同样会失去优势。
• 能够以最方便的方式运行每个软件堆栈及其依赖项——独立于主机的发行版、libc 和其他库版本——是一个很大的好处，但需要多次加载共享库（当它们的版本不同）具有您期望的成本。

等等。 这些成本对您在您的环境中的实际影响有多大——包括您的网络访问模式、您的内存限制等——是一个很难提供通用答案的项目。

Answer 3

这里的一些基准为Docker based memcached server对host native memcached server使用Twemperf基准测试工具https://github.com/twitter/twemperf与5000个连接和20K连接速率

基于 docker 的 memcached 的连接时间开销似乎与上述白皮书一致，其速度大约是本机速度的两倍。

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

这是使用 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

Answer 4

运行时库比较

我将解决有关运行时库的容器运行时性能成本的问题。

速度：Musl 与 glibc

在 Apline Linux 容器中，运行时库由 Musl代替 glibc 提供，根据下面的链接，两者之间可能存在性能差异：

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

我读过研究这个主题的各种意见，Musl 既小巧又现代得多，还赋予了 glibc 一定程度的更高安全性。 然而，无法找到任何数据来支持这些观点。

兼容性

即使 Musl 更快更安全，它也可能会出现兼容性问题，因为Musl 与 glibc 有本质上的不同。 我发现如果我使用apk创建一个 docker 图像来拉入我的包，当然没有功能问题。

结论

如果性能很重要，请使用 Musl 切割 (2) 个容器，一个是 Alpine Linux，另一个使用使用 glibc 的发行版并对其进行基准测试。 当然还有在评论中发布您的结果！！！！