tcp服务器accept的作用,在Xen下，为什么TCP accept（）性能如此糟糕？

在Xen下，我的服务器可以接受()新的传入TCP连接的速率确实很差。在裸机硬件上进行的相同测试显示速度提高了3-5倍。

在Xen下怎么这么糟糕？

您可以调整Xen来提高新TCP连接的性能吗？

是否有其他虚拟化平台更适合此类用例？

背景

最近，我一直在研究在Xen下运行的内部开发Java服务器的一些性能瓶颈。服务器使用HTTP并回答简单的TCP连接/请求/响应/断开连接呼叫。

但是，即使在向服务器发送大量流量时，它每秒也不能接受超过7000个TCP连接(在8核EC2实例上，运行Xen的c1.xlarge)。在测试过程中，服务器还表现出一种奇怪的行为，其中一个内核(不一定是cpu 0)的负载超过80％，而其他内核几乎保持空闲状态。这使我认为问题与内核/底层虚拟化有关。

在裸机，非虚拟平台上测试相同的方案时，我得到的测试结果显示，TCP accept()的速率超过35000 /秒。这是在运行Ubuntu的Core i5 4核心计算机上，所有核心几乎完全饱和。在我看来，这种数字是正确的。

再次在Xen实例上，我尝试启用/调整sysctl.conf中几乎所有的设置。包括启用“ 接收数据包控制”和“ 接收流控制”以及将线程/进程固定到CPU，但没有明显的收获。

我知道运行虚拟化时性能会下降。但是到这个程度呢？较慢的裸机服务器胜过虚拟机。8核心减少了5倍？

Xen确实是这种预期的行为吗？

您可以调整Xen来提高新TCP连接的性能吗？

是否有其他虚拟化平台更适合此类用例？

重现此行为

在进一步调查并查明问题时，我发现netperf性能测试工具可以模拟我遇到的类似情况。使用netperf的TCP_CRR测试，我从不同的服务器(虚拟服务器和非虚拟服务器)收集了各种报告。如果您想对某些发现做出贡献或查找我当前的报告，请参阅https://gist.github.com/985475

我怎么知道这个问题不是由于软件写得不好？

该服务器已经在裸机硬件上进行了测试，并且几乎饱和了所有可用内核。

使用保持活动的TCP连接时，问题消失了。

为什么这很重要？

在ESN(我的雇主)，我是Beaconpush的项目负责人，Beaconpush是用Java编写的Comet / Web Socket服务器。尽管它的性能非常好，并且在最佳条件下几乎可以饱和分配给它的所有带宽，但是它仍然受到新TCP连接建立速度的限制。也就是说，如果用户频繁流失，那么用户来回频繁，则必须建立/删除许多TCP连接。我们尝试减轻这种影响，以使连接尽可能长寿。但是最后，accept()性能才是使我们的内核无法旋转的原因，我们对此并不满意。

更新1

有人将此问题发布到Hacker News，那里也有一些问题/答案。但是，我将不断努力，以我发现的信息来使这个问题保持最新。

硬件/平台我已经在以下方面进行了测试：

实例类型为c1.xlarge(8核，7 GB RAM)和cc1.4xlarge(2x Intel Xeon X5570，23GB RAM)的EC2。使用的AMI分别为ami-08f40561和ami-1cad5275。有人还指出，“安全组”(即EC2防火墙)也可能会受到影响。但是对于此测试方案，我仅在localhost上尝试过消除此类外部因素。我听到的另一个谣言是，EC2实例的推送速度不能超过100k PPS。

两个运行Xen的私有虚拟服务器。在测试之前，一个负载为零，但没有影响。

Rackspace的专用Xen服务器专用。大约有相同的结果。

我正在重新运行这些测试，并在https://gist.github.com/985475上填写报告。如果您想提供帮助，请贡献您的数量。这很容易！

(行动计划已移至单独的综合答案中)