相同级别的CPU上的Sysbench，为什么Google VM比AWS ec2快得多？

在大多数中小型实例中，AWS积极地在多个虚拟机之间共享CPU时间。 这意味着从客端出现“正在运行”的任何进程都可以真正在主机端“挂起/等待”，从而降低总体性能。

其他云提供商似乎提供的分配时间稍低，即使是小型实例也是如此：例如，从一台小型的Azure机器上，我获得了比类似的AWS实例快得多的CPU性能。

然而，VMS供应/大小可能相当复杂，有许多select需要考虑。 例如，当一台AWS机器闲置时，它收集“CPU信用”，用于快速和短期的交易。 欲了解更多信息，请看这里 。

当你在大多数的云提供商上得到一个普通的虚拟机时，你没有获得专门的资源，否则你会得到一个通常更加昂贵的专用服务器。 当然，这取决于提供商的实施，但总的来说总会有过度承诺和超额认购。 密度越高（硬件越多，虚拟机越多），您可以更好地稳定单个虚拟机的性能，但这一切取决于多种因素，如CPU调度algorithm，密度，虚拟机负载平衡等。

例如，Azure试图保证不同的虚拟机大小有一定的性能，但实际上它在许多不同的因素上是非常不同的，虚拟机并不是单独运行在硬件上，而是与许多其他的一起运行。

其他基准

我在VPS基准testing中发现了一个有趣的基准。 请注意，他们有不公平的图表，在规模上不包括0，所以graphics几乎是无用的。 testing背后的数字看起来很好。

他们的testing将AWS t2.small（1核心，2GB RAM）与GCE n1-standard-1进行比较。 对于n1标准来说，t2实例并不是一个很好的比较，与具有恒定CPU的GCE相比，它们具有更好的CPU性能，但这是我能find的唯一合适的testing。

t2实例被声称在较老的AWS硬件（m1代）上运行，而M3 / M4 AWS实例较新。 GCEtesting也是最近完成的。

个人testing

这些都是指上面链接的testing。

CPUtesting接近，在3％以内。

文件IO随机读取根本不closures。 AWS有24Mbps和1787Mbps的GCE。 我知道在AWS中，您的I / O与您的实例types密切相关，小型实例的I / O比大型实例less得多。 鉴于这个巨大的差异，其他testing大致相似，我希望看到这个重新testing之前，我相信数字。 我已经读过，GCE对于networkingI / O确实做得很好。 也可能是GCEtesting是使用本地SSD完成的，AWStesting是使用networking附加存储完成的。

其他IOtesting大致相似。 有时候AWS比较高，有时GCE比较高，但是没有明确的赢家。

内存testing大致相同，AWS将削减谷歌。

笔记

对于任何提供商的任何实例的任何单个testing可能由于各种各样的原因而低。 过度configuration的硬件，嘈杂的邻居占用更多的资源，以及CPU窃取只是一些例子。

一个好的testing将使用各种testing（CPU，I / O，内存等），并且至less在三个独立的虚拟机上运行。

结论

尽pipe实例types和硬件是完全不同的，但AWS和GCE在这些合理有效的文档testing中performance出大致相似。

我希望看到@StanHou做了显着更强大的，有据可查的testing来比较性能，而不是依赖于单个实例上的单个testing。