Bitcurrent和 Webmetrics针对5种不同的云平台——Amazon、Google、Rackspace、Salesforce.com和Terremark进行了为期一个月的大量测试,尝试测量每种平台的性能。其中一个结论是每种平台针对不同类型的应用各有所长。 为了测试云性能,报告作者选取了4种类型的测试并在5个云平台上运行5个原生应用作为基准。 测试 - 请求小对象——1x1像素的GIF图片
- 请求大对象——2MB大小的图片
- 执行CPU高消耗的任务——100万次sine(正弦)和加法操作。由于Salesforce.com的平台限制,负载是10万次。
- 执行IO高消耗的任务——通过MySQL数据库查询50万行的数据表(Amazon、Rackspace、Terremark使用了显式缓存、Salesforce.com使用了data store,Google使用了BigTable)。
原生应用 为何给原生应用作基准测试,作者选择了5款为平台定制开发的真实网站。针对Salesforce.com的网站采用Apex编写,针对GAE的应用采用Java和Python编写,网站运行在Amazon和Rackspace中Xen服务器上的Linux系统上,而Terremark则运行在VMware VM上。应用的名字没有被公开。 为了实施测量,作者使用了 WebMetrics的服务,在一个月内从世界不同地方以不同的间隔时间发送请求。 Salesforce.com和GAE提供了PaaS服务,而Amazon、Rackspace和Terremark提供了IaaS服务。 结果 5个云平台上4种测试的延迟如下所示: 所有平台针对小对象都表现不错,而在大对象方面,PaaS平台比IaaS更出色。Salesforce.com在CPU高消耗的任务中,虽然计算压力只有其他平台的10%,但是表现依然糟糕。Google和Rackspace在IO测试中脱颖而出。 针对原生应用的测试结果如下所示: PaaS云表现更好,之后是Amazon和Rackspace,而Terremark由于响应时间在12秒的延迟所占比例较大而排名末尾。 结论 性能测量报告的作者总结了测试过程中的经验教训并列举了一些结论: 小心你的邻居: 我们已经确切地发现一些云应用会同时出现性能下降,所以你肯定会被使用同一片云的其他应用所影响。 理解你所在云的配置: 上文显示的图表明不同的云擅长不同的任务。你需要选择虚拟机器的容量——CPU、内存等等——以便提供出色的性能。 安插个内线: 当你制定监控策略时,需要定制代码以执行后台函数,可以尽快地找到问题。 根据工作负载选择Paas还是IaaS平台: 如果你乐于重构你的应用以利用“大数据”系统如BigTable,那么选择PaaS云伸缩性很好。另一方面,如果你需要独立的机器,那么不得不在IaaS配置中构建弹性。 Big data不是白来的: 使用大型、稀疏的数据存储可能很好,但是这需要花时间来导入(在Google的测试中用了37个小时!),这可能不符合你的应用使用模式。 监控使用情况: 在PaaS中,如果超过了速率限制,你的用户会得到错误信息。 排除故障很困难: 为了定位问题,你需要分析互联网的数据、云提供商的数据和应用的各个层次。当你使用专有的基础设施时,无需花费太长时间来排除第三方的问题(如共享带宽引起的竞争或者I/O阻塞)。 PaaS意味着你们在同一只篮子里: 我们注意到如果你是用PaaS平台,当云性能下降时,所有应用也紧随其后。在IaaS中,存在更多独立的CPU和服务器的快速反应——但是你仍然会面对共享存储和网络带宽的竞争。
注意:因为测试结果受不同类型的工作负载、代码、步骤、实际部署环境和其他因素的影响,报告的作者建议读者仅作参考。本研究并不想特意推荐某一款云平台。
|