IBMResearch发表了一篇关于容器和虚拟机环境的性能比较的论文。本文以Docker和KVM为研究对象，阐述了Docker使用NAT或AUFS的开销，并对在虚拟机上运行容器的做法提出质疑。作者在原生、容器化和虚拟化环境中运行了CPU、内存、网络和I/O的基准测试。其中，KVM和Docker分别作为虚拟化和容器技术的代表。Benchmark还包括不同环境中的Redis和MySQL工作负载示例。对于小数据包和多个客户端，Redis专注于网络堆栈的性能。而MySQL侧重于内存、网络和文件系统性能。结果表明，在每项测试中，Docker的性能都等于或超过了KVM。KVM和Docker在CPU和内存性能方面都引入了显着但可以忽略不计的开销。但是，对于I/O密集型应用程序，两者都需要进行调整以减少开销的影响。使用AUFS存储文件时，Docker的性能会下降。相比之下，使用卷（volume）可以获得更好的性能。卷是一个专门设计的目录，存在于一个或多个容器中。通过这个目录可以绕过联合文件系统（unionfilesystem）。这样它就没有存储后端可能带来的开销。默认的AUFS后端会导致显着的I/O开销，尤其是当有多层目录深度嵌套时。Docker的默认网络选项--net=bridge也引入了由于NAT重写数据包而导致的性能开销。当数据包发送和接收的速率变高时，这种开销变得很明显。使用--net=host可以提高网络性能。此选项告诉Docker不要为容器创建单独的网络堆栈，并允许容器完全访问主机的网络接口。但是，使用此选项时要小心。因为它允许容器中的进程像其他根进程一样使用一个值较小的端口；并允许容器中的进程访问本地网络服务，例如D-bus。这允许容器内的进程做一些意想不到的事情，比如重启主机。尽管KVM的性能自诞生以来有了很大的提升，但它仍然不适用于对延迟敏感或具有高I/O访问率的工作负载。因为每次I/O操作，都会增加一些开销。这种开销对于耗时较少的I/O操作是有意义的，但对于较长的I/O操作可以忽略不计。基于这些测试结果，论文对使用虚拟机实现IaaS的做法提出了质疑：传统观点（在某种程度上，这种观点存在于年轻的云生态中）是虚拟机用于IaaS，容器用于PaaS。我们没有找到技术上的理由来证明这一点，尤其是证明基于IaaS的容器提供更好的性能或更容易部署。容器可以弥合IaaS和非虚拟化服务器之间的差距，因为容器提供了在不使用虚拟机的情况下控制和实现物理机性能的方法。虽然在虚拟环境中运行容器是一种常见的做法，但该论文建议直接在物理Linux服务器上运行它们。否则，由于虚拟机的性能开销，与直接在非虚拟化Linux上运行相比，这种做法不会获得任何额外的好处。参考英文原文：ComparingVirtualMachinesandLinuxContainersPerformance翻译链接：http://www.infoq.com/cn/news/2014/08/vm-containers-performance?utm_campaign=infoq_content&utm_source=infoq&utm_medium=feed&utm_term=global
