基于google-app-engine的云计算内部性能测量(最终版)-毕业论文.doc

基于Google App Engine的云计算内部性能测量摘要随着网络应用的日渐丰富和网络技术的飞速发展，云计算已经越来越成为现今网络业务部署时的首选，云计算平台具有虚拟化、性能高、部署灵活而弹性大等特点，但作为一个新生事物，云计算的性能尤其是内部性能是否达到供应商宣称的指标，和传统的主机相比差异如何已经是摆在人们面前的重要课题，因此本文根据云计算和云平台的特点，设计并实现了针对云计算内部性能包括计算能力及边界、缓存机制和抖动的测量方法，并给出了测量结果。另外本文还给出了针对云计算和云平台的测量在测量方法学上的建议和结论。关键字：云计算；GAE；网络测量AbstractAs a developing application of network, cloud computing has a growing priority in network application deployment with its characteristics of high virtualization, performance, and flexibility. However, this new application is also challenging the provider by its service standard, especially when users try to compare with traditional services. Therefore, the measurement of cloud computing becomes a new topic in network measurement. This article utilizes Google App Engine to implement several tests on cloud platform, including computing performance, computing limitation, cache, jitter and etc. Also it discusses the distinction of measurement methodology on cloud computing and cloud platform.Keyword：Cloud computing；GAE；network measurement1前言云计算（Cloud Computing）是一种新兴的商业计算模型，是并行处理，分布式处理和网格计算的发展或者说是这些计算机科学概念的商业实现，云计算可以利用自身优势提供传统计算模型所不能或者较难提供的高效、大规模、高灵活的服务。但是云计算服务提供以及服务资源本身的研究、实践尚处于发展阶段，多数研究成果是基于传统应用的改进或者仅能解决云计算技术的一小部分问题，平台的性能和可靠性有待检验。虽然当前有一些对现有知名云平台的测试，但是都是针对单个平台本身的性能分析或者是多个平台之间的性能比较，尚未有将云平台和单机对比的测试，而这方面正是本文的出发点。由此，本文提出了基于客户端的对Google App Engine的云计算内部性能的测量办法，首先确定了针对计算力在网络条件下的性能表现，具体为计算能力及边界，缓存机制和抖动这三项测量内容，从而帮助客户判断，相较于部署于单独主机上的情况而言，将业务迁移到云平台下是否有价值。根据这样测量内容和测量目标，本文采取了基于客户端发起，部署业务配合计时器的测量方式，通过提交复杂计算任务以及多次数、多时间段的测量，从而得到最终的测量结果。本文的内容安排如下：第二节介绍云计算的发展与现状，由此提出测量的主要目的和方向，然后再第三节具体给出针对Google App Engine的性能测量方案，包括测量的内容与测量目标，并介绍了具体测量方式。第四节给出测量结果的分析，包括针对计算能力、缓存能力和抖动方面的结果，最后给出整个测量的一个最终结论，第五节则对本文进行了一下总结并对将来的工作进行了展望。2云计算的发展与现状2.1云计算的概念云计算（Cloud Computing）是一种新兴的商业计算模型，是并行处理，分布式处理和网格计算的发展或者说是这些计算机科学概念的商业实现。它将计算任务分布在大量计算机构成的资源池上，使各种应用系统能够根据需要获取计算力，存储空间和各种应用服务。其核心是数据中心，硬件是普通的符合工业标准的服务器，这些服务器由大型数据处理中心管理，数据中心按客户的需要分配计算资源，可以达到域超级计算机同样的效果。对于企业和个人用户而言，他们可以极低的成本投入获取较高的计算能力，从而节省了购买硬件设备，设备保养及升级的支出。可以看出，“云”即网络中各种资源，“计算”则是能力，包括信息处理，存储，检索和交互等，从技术层面看，云计算最核心的技术是虚拟化，将网络上的硬件资源整合成网络的服务能力。从服务层面看，云计算是一种新的商务模式，服务商利用虚拟化技术为用户提供优质价廉的专业化，估摸化的信息服务。从应用层面看，云计算是一种新的应用体验，用户就像用水电般使用互联网服务，像在银行存钱般在网络上存储自己的信息。近些年来云计算技术吸引了很多的注意。传媒、IT界和科技界都对它表示了极大的兴趣并抱有肯定的态度,因为它能够极大地发挥网络资源的价值。2008年5月MerrillLynch1曾做过估计,云计算给商业应用带来的成本收益可达35倍,而对客户应用甚至可超过5倍。2008年6月Gartner2新闻稿声称,“云计算的影响将不亚于电子商务”。对于云计算重要性和影响的这种肯定态度,使其市场前景变得非常的乐观。2008年10月, IDC曾预言,到2012年对云计算的投入将翻3番,达到420亿美元;它还报道说,在当前这种经济下滑时代,云计算的成本收益将会引起更多的关注3。云计算的这种积极的市场前景,让人感到它将成为通向绿色IT的基本途径。2.2云计算的相关应用现状云平台屏蔽了底层的软硬件实现细节，并且提供链接服务的标准接口，使得所有连接Internet的用户都可以方便的接入云平台使用计算资源。目前已实现的云计算平台都符合云计算的基本技术框架，但是各个公司的侧重点又有所不同。大致可以分为三类：基于虚拟技术停工底层基础资源服务；统合云计算平台内部资源提供功能特化的上层服务资源；统合平台内部的基础资源，提供基于网络服务的计算平台。但是无论基于何种目标，云计算平台都应具备以下三个特点：（1）用户不必关心平台底层的实现。用户使用平台，或者使用云平台发布第三方应用的开发者都不必理解云内部的细节，他们只需要调用平台提供的借口就可以再云平台中完成自己的工作。（2）云平台非常灵活，其规模可以按照实际需求进行调节。利用虚拟化技术，云平台提供商可以实现按需提供服务，这一方面降低了云的成本，另一方面保证了用户的需求得到满足。（3）云平台基于大规模的数据中心或者网格，因此云平台可以提供高性能的计算服务，并且对于云用户，云的资源几乎是无限的。目前较为著名的云计算平台有以下几个：l Microsoft Azure PlatformMicrosoft Azure Platform4提供了托管云服务需要的所有功能，包括运行时环境，如Web服务器、计算服务、基础存储、队列、管理服务和负载均衡，Windows Azure也为开发人员提供了本地开发网络，在部署到云之前，可以在本地构建和测试服务，Windows Azure的三个核心服务分别是计算(Compute)、存储(Storage)和管理(Management)。计算：计算服务在64位Windows Server 2008平台上由Hyper-V支持提供可扩展的托管服务，这个平台是虚拟化的，可根据需要动态调整。存储：Windows Azure支持三种类型的存储，分别是Table，Blob和Queue。它们支持通过REST API直接访问。注意Windows Azure Table和传统的关系数据库Table有着本质的区别，它有独立的数据模型，Table通常用来存储TB级高可用数据，如电子商务网站的用户配置数据，Blob通常用来存储大型二进制数据，如视频，图片和音乐，每个Blob最大支持存储50GB数据，Queue是连接服务和应用程序的异步通信信道，Queue可以在一个Windows Azure实例内使用，也可以跨多个Windows Azure实例使用，Queue基础设施支持无限数量的消息，但每条消息的大小不能超过8KB。任何有权访问云存储的帐户都可以访问Table，Blob和Queue。管理：包括虚拟机授权，在虚拟机上部署服务，配置虚拟交换机和路由器，负载均衡等。Windows Azure Platform的主要用途是：(1)给现有打包应用程序增加Web服务功能;(2)用最少的资源构建、修改和分发应用程序到Web上;(3)执行服务，如大容量存储，批处理操作，高强度计算等;(4)快速创建、测试、调试和分发Web服务;(5)降低构建和扩展资源的成本和风险;(6)减少IT管理工作和成本。l Amazon Elastic Compute Cloud (EC2)EC25用户可以通过简单的网络服务接口使用或者配置资源，将其申请的资源作为网络虚拟机完全的控制。这种申请资源并且启动新服务实例的时间间隔将达到分钟级别，这意味着EC2可以迅速满足用户的请求，并且以细粒度分析用户的使用情况。无论是扩展规模还是减少规模，系统都可以满足。从技术架构上来说，EC2生成提供了一个真正完全虚拟化的计算环境，只要用户申请资源，EC2就可以提供可以符合多种系统需求的计算环境以及响应的资源。但其主要技术层面在虚拟化层面，其提供的服务是利用虚拟化技术提供的基础实施服务资源，如存储、虚拟机等。EC2特点包括如下3点：(1)弹性。所谓弹性计算云，其首要的优势当然是可以提供弹性的计算能力。所谓弹性就是指在用户的需求增加或者减少时，可以迅速的满足用户在计算规模上要求的变化。(2)灵活。EC2提供的平台是底层资源，而用户在其上运行何种操作系统、何种应用的都是很灵活的。通过配置内存、CPU以及实例的存储用户可以为各种环境配置出合适的平台。(3)可靠。EC2对于运行的实例都提供可以在出问题是快速替换的备用实例。实例运行的环境非常可靠，EC2的服务级别协议对于所有的地区都有99.95%的保证。l Google App EngineGoogle App Engine6提供了一个强大的分布式数据存储服务，其中包含查询引擎和事务功能。就像分布式网络服务器随访问量增加一样，该分布式数据存储区也会随数据而增加。可让用户在 Google 的基础架构上运行网络应用程序。App Engine 应用程序易于构建和维护，并可根据用户的访问量和数据存储需要的增长轻松扩展。使Google App Engine将不再需要维护服务器，只需上传您的应用程序，它便可立即为用户提供服务。在 App Engine 中，用户只需为使用的资源付费。没有设置成本，也没有重复的费用。用户的应用程序使用的资源，如存储空间和带宽以千兆字节衡量，并以有竞争力的费率收费。用户可以控制自己应用程序可以消费的最大资源量，使其一直保持在预算范围内。可以免费开始使用 App Engine。所有应用程序都可以使用多达 500 MB 的存储空间，以及可支持每月约 500 万页面浏览量的足够的 CPU 和带宽，完全免费。用户给应用程序启用付费后，用户的免费配额将提高，用户只需为使用的超过免费水平的资源付费。App Engine 包括以下功能：(1)动态网络服务，提供对常用网络技术的完全支持;(2)持久存储空间，支持查询、分类和事务;(3)自动扩展和负载平衡;(4)用于对用户进行身份验证和使用 Google 帐户发送电子邮件API;(5)一种功能完整的本地开发环境，可以在用户的计算机上模拟 Google App Engine.2.3云计算的挑战和本文目标云要向许多不同的客户提供服务，因而云服务的用户并不知道他所用到的服务器上都有哪些任务正在运行，在基础设施的可靠性、性能和服务质量(QoS)等方面,用户不得不依赖于云提供者所作的承诺。此外云计算和云数据管理中一个跨领域问题就是供应商要在功能和开发代价上作权衡。目前，早期的云计算提供的API比传统的数据库系统的限制多得多。他们只提供一个极小化的查询语言和有限的一致性保证。这给开发者带来更多的编程负担，同时对于一个功能完备的SQL数据库允许服务供应商提供更多的预期服务和服务级别协议也是很难达到的。其次，易管理性在云计算中极其重要，这也带来新的挑战。和传统的系统相比，受工作负载变化幅度大和多种多样的共享设备的因素影响，云计算中管理任务更加复杂。大多数情况下，由于云系统中机器数量太大，数据库管理员和系统管理员很难对所有机器进行全面周全的人工干预。所以迫切地需要自动管理的机制。本来混合负载就很难调优，但在云平台中这种调优是不可避免的。上文所述的几种应用都属于原始的基础设施和平台，并没有强大的管理能力，随着竞争的越发激烈，如何管理这些原始的功能就成为了供应商的一个分水岭。重要的问题是对于当前各种云服务提出的性能承诺的验证有待展开。当面对如此美妙的云计算画卷时，我们应该看到困难和问题，故应该持谨慎乐观态度，虽然云计算的时代已经逐步到来，告别有限的计算资源，告别耗时耗力的维护工作，市场需要云计算，而IT业的进一步发展也确实需要云计算。但是不可否认，运营级的应用和云计算的真正接轨还是有很长的路要走。有学者指出：云计算的基础设施技术还需要7年时间来成熟。2009年的云计算市场还是处在早期市场，多数企业仍处于观望阶段。根Berkeley大学的相关研究7，云计算技术距离完全实现其愿景尚存在的10大障碍：服务的可用性的保证；数据锁定，平台之间数据的转移；数据保密性和可审计性；数据传输瓶颈；性能不可预测性；高效、细粒度的弹性存储；大型分布式系统中易于存在bug；高效准确的计量；服务供应商以及平台其它用户的声誉命运共享；新的计算资源、服务商业模型带来的软件许可证问题。同时关于云计算服务提供以及服务资源本身的研究、实践尚处于发展阶段，多数研究成果是基于传统应用的改进或者仅能解决云计算技术的一小部分问题。云计算可以利用自身优势提供传统计算模型所不能或者较难提供的高效、大规模、高灵活的服务。正是由于上述诸多问题尚待解决，平台的性能和可靠性有待检验，如公布Google App Engine应用开发和托管服务企业版2周后，Google便承认该产品的数据存储子系统存在性能问题。又如关于EC2云的一个最常被问起的就是其存储系统S3以及它的运算平台EC2的性能到底如何，事实上 EC2不会在你的服务器负荷大大加重时自动调整你的应用，开发人员仍然需要管理可扩展性问题。可见对于当前各种云服务提出的性能承诺的验证有待展开，当前已有一些相关工作如：HostedFTP.com基于其内部测试的性能数据创建了这份报告，其主要内容是讨论当在EC2实例和S3之间存取文件时所能获得的性能表现。使用线性性能模型来测试S3和EC2之间的文件存取。并进行数据分析的以确定固定交易开销和可变带宽开销，最终得出如下结论：（1）存取文件时的可变带宽开销都在10到12MB/s之间；（2）存储文件时的固定交易开销大概是140ms，读取文件时固定交易开销可忽略不计。还有上有一场关于Google App Toolkit的公开负载测试，Google Web Toolkit和RIA专家Didier Girard已经构建了一个简单的GWT应用并放在Google App Engine上，目标是10分钟内能达到4000个独立访问者。一天内有100000个独立访问者，以测试应用可以经受住高负载的考验。此外Bitcurrent和Webmetric公司针对5种不同的云平台Amazon、Google、Rackspace、S和Terremark进行了为期一个月的大量测试，尝试测量每种平台的性能，其中一个结论是每种平台针对不同类型的应用各有所长。由此可见对于不同的平台需要从理论尤其是实验环节不断的对云的性能进行测量并做出评估，以发现其与现有计算技术相比的优势或者不足之处，同时还需将各个平台的测量数据做比较以分析不同平台对相同应用的处理能力，找出差异和共性。测量的方面有很多，可以从几个最重要的方面入手，如云计算能力和云存储能力。本文的测量的目标：计算力在网络条件下的性能表现，具体为计算能力及边界，缓存机制和抖动。3基于 Google App Engine的性能测量 本小节给出了基于Google App Engine的性能测量的具体方案，首先提出测量的内容和测量的目标，然后针对具体内容设计了相应的测量方案。3.1 测量内容与目标对云计算平台的性能测量可以分为外部性能和内部性能两大类，外部性能包括云平台的网络性能（如抖动、时延、丢包率等）、拓扑和流量等指标，内部性能则指运算能力、存储能力以及其随时间产生的抖动等指标。对于云平台的应用者而言，外部的网络性能是云平台本身不能保证也无法保证的，而云平台内部的运算能力、存储能力等指标则是值得关注的，因为这些指标决定了业务部署于云平台之后能否取得预想中的效果。因此本文主要针对云平台的内部性能来进行测量，其内容包括：1、计算能力及边界所谓计算能力是指一个业务部署于云平台之后，其被分配到的用于业务自身的计算资源和能力。显然根据云计算的特点，这个能力是随着业务需要而可以动态变化的。而部署业务的客户往往关注的是业务所得到的计算能力的具体内容和范围，或者说，与常规的基于主机的部署方式相比较，云平台上部署的业务能够得到相当于什么规格和能力的主机的CPU计算能力，与此同时，客户还关心这个计算能力的范围，因为云平台分配给用户的计算能力虽然有弹性，但不可能无限增长，因此用户需要了解其限制在什么范围，由此来决定部署其上的业务的特点和内容。2、缓存机制 对于基于网络的应用系统和业务来说，如何快速的对用户访问进行响应是一个非常重要的问题，在基于主机的部署方式里面，利用主机的缓存机制来加快对用户的访问相应是一个非常常规和有效的手段，很多比较流行的应用（例如一些关系型数据库和面向对象技术之间的中间件）都必须有服务器的缓存支持，当业务转移至云平台时，缓存机制是否存在，如果存在，其性能与主机模式的性能有无差异也是客户关心的问题。3、抖动对于部署的业务来说，是否能够实现7*24小时级别的平稳运行是非常关键的，众所周知，由于用户本身的访问具备波动性和主机性能的固定，因此抖动问题是部署业务是的一个重要参考因素，而在具备较强弹性的云平台下的业务在一天各个时间段的性能是否稳定，是否仍然具有抖动的问题也是需要测量的一个内容。综上所述，相较于部署于单独主机上的情况而言，将业务迁移到云平台下是否有价值，业务本身的性能与付出的代价相比是否值得有赖于对云计算内部性能的相关内容的测量，所以本文的测量目标位：以对比本地主机与基于Google API的“云计算”Google App Engine关于运算能力、缓存机制和抖动情况来测量“云计算”的性能情况。另外由于云计算平台免费开放的存储空间和应用数量有限，因此本测试仅测试“云计算”Google App Engine的CPU性能、缓存和抖动方面的指标，并不考虑其存储性能、传输性能等其他性能。3.2 测量方式对于计算能力、缓存机制和豆豆这三个不同的测量内容，必须通过不同的测试方法来衡量，系统性能，分析性能变化的特点。本文通过两种不同的方式来测量计算能力、缓存机制和抖动。1、计算能力和缓存机制的测量方式 对于云平台的计算能力主要可以通过向云平台部署需要复杂计算的业务，然后在客户端出项业务提出访问请求，然后通过测度计算任务完成需要多少时间来测量计算能力，通过连续多次提交相同的访问请求，测度不同的请求返回的计算时间是否有差异来测度缓存机制的存在与否（若存在则可测量其性能）。测试方法主要有：a） 绘制回字矩阵对应的算法：用二维数组输出成回字矩阵，为简单的循环算法。该测试对应的业务算法复杂度不高，主要目的是研究低复杂度业务在云平台上运行时的性能情况b）大数乘法对应算法：定义两个长整型数组存放被乘数与乘数，把两个长整型逐位转存到两个整型数组中，单独处理乘积的符号位，相乘过程中连续进位；数组左移位，以保证错位相加。该测试对应的业务算法复杂度较高，但受编程时大数定义的限制，乘法本身不易溢出，因此算法不会逼近云平台的性能极限，主要目的在于研究较高复杂度时的性能情况c）计算对应的算法：使用的莱布尼茨级数 /4=1-1/3+1/5-1/7+1/9来进行计算，算法采用递归实现。该测试对应的业务算法复杂度很高，且本身能够逼近甚至超出系统的性能极限，主要目的在于研究高复杂度稳定性及系统性能极限在给出这些测试方法后，分别对这些算法取不同的规模参数，其规模用为101、102、103、1012序列，即计算10、100、1012规模的回字矩阵，或计算10、100、1012位长的，或者10、100、1012次的大数乘法。另外再给出对照测量的平台为：本地主机A：OS：Windows Vista home Premium Service Pack 2，CPU： Intel Core 2 Duo CPU T7500 2.2GHZ，RAM：2GB本地主机B：OS：Windows 7 Professional，CPU：Intel Core 2 Quad CPU Q94002.66GHZ，RAM：6GB2、抖动的测量抖动的测量是在计算能力的测量算法基础之上进行的，主要思路是对比不同时段访问部署于Google App Engine的计算能力测量的业务，通过分析不同时段不同负载情况下Google App Engine的效率与稳定性状况来得出结论最后给出所有测量方式的基本流程：结束测试算法计时器开始计时器结束图4-1 测试程序流程 其主要思路为部署计时器，计时器的作用是在业务本身的代算法码部分在具体执行之前和执行完毕之后分别采样时间数据，然后返回两个时间数据之差，由于时间采样本身是在云平台上进行的，因此可以避免网络本身的延迟造成的误差和影响，能够真实的反映云平台的实际性能。4测量结果与分析4.1 计算能力及边界根据Google App Engine的技术报告，该平台向客户收费时是以类似于计算能力的CPU时间（收费）单位来计算的，因此本文的测量方法对计算能力的衡量时也通过单位CPU 时间来进行的，该单位给出的定义为：一次计算所对应的CPU时间即指云平台处理请求对应业务的总处理时间，包括运行应用程序和执行数据存储区操作所花的时间。CPU 时间以“秒”为单位报告，其等于 1.2 GHz Intel x86 处理器在该时间量中能够执行的 CPU 周期数。首先给出实际测出的CPU时间和Google App Engine给出的收费数据的比较结果：图4-2 实测CPU时间与GAE文档内容的比较 图中结果表明Google App Engine提供的运行应用的时间与其CPU占用量（cpu_ms）接近正比，意即Google App Engine的计费与业务实际耗费的计算资源规模是对应的，说明本文的测量方法是合理和有效地。由此给出三种测试方式得到的测试结果进行标准化之后，得到计算能力的测量结果为：图4-2 云计算能力与本地主机计算能力的对比测量结果表明：算法运行耗费时间在10-1000ms内，Google App Engine比本地主机A效率高2-4倍，比本地主机B效率略高但值得注意的是，算法运行耗费时间在1000ms以上，Google App Engine效率降低甚至超出受限能力范围导致无法响应，即计算能力的边界是存在的。其范围的测量结果如下图 图4-3 GAE提示的计算能力边界如图所示，应用运算350ms（即650cpu_ms）以上时，Google App Engine后台显示Error，即将达到CPU性能临界应用运算500ms（即1000cpu_ms）以上时，Google App Engine后台显示Critical(most severe)，即将超出可用CPU性能临界，该测量结果表明，云平台的计算能力的边界是由云平台的供应商确立的，部署于云平台的业务获得的性能虽有一定的弹性，但仍不是不受任何限制的，根据Google App Engine的文档表明，用户部署于云平台的资源限额为下图所示：图4-4 GAE给出的资源4.2 缓存能力在计算能力的测量基础之上，通过对多次重复提交测量请求并记录结果，分析这些结果的波动，得到的测量结果如下：图4-5 云平台的缓冲测量 测量结果显示：初次运行应用速度相较之后稳定多次运行速度慢1倍以上，之后各次运行时间仍然符合按复杂性增长，根据这个测量结果，可以做出的以下猜想：第一次部分耗时用于新应用的部署，其后业务运算时并无应用到缓存机制，因此云平台本身不提供业务单独使用的缓存机制。4.3 抖动在计算能力的测量基础上，通过在一天的不同时段进行同样的测量，然后比较结果可以得到对抖动的测量结果：图4-6 云平台计算能力抖动的测量 根据测量结果，可以得到的结论是：一天内各个时段Google App Engine计算能力性能较稳定，抖动在5%以内，另外有个别天数Google App Engine服务器出错应用无法打开，可能与服务可用性有关4.4小结云计算作为一种新型的分布式计算平台，它通过Internet向用户按需提供一个抽象的、虚拟化的、规模可以动态改变的、可管理的计算资源、存储资源、平台、服务，因而从一个具体的网络节点（或者物理网络）转化为一种全新的互联网服务形式。而针对这样的一个转变，传统的网络测量尤其是针对具体网络节点的测量方法、测量内容和目标也应随之而变。所以本文针对Google提供的云平台Google App Engine进行了网络测量。在这测量过程中，可以得出以下几个较有意义的结论：首先，针对云计算的特殊形式，本文提出了新的测量对象-云平台。而对这个新的测量对象，本文也提出了新的测量内容，这些内容不再是传统网络节点的例如流量、拓扑、延迟等指标，而是针对部署于其上的业务所至关重要的指标：计算能力、缓存能力、抖动情况等。其中，计算能力尤为重要，是一个关键指标；而抖动情况反映了云平台自身在面向所有业务的使用者时的性能及其稳定性，也决定了业务的质量。其次，针对云计算的特殊形式，本文也对传统的测量方法做出了扬弃，传统的测量方法可以分为主动测量和被动测量两种，而利用云平台自身提供的服务，可以实现了主动测量与被动测量的结合，由于云平台上得计算能力是作为服务的一部分，其实际是受到了网络和云的双重影响，因此，当对网络的测量扩展到云平台服务内部时，对云的计算能力的测量方法也必须改进，本文采用测试程序进行测量是对云的主动测量，同时云给出的资源消耗记录则可以作为一种被动测量，而配合两种测量可以得到合适的测量结果。最后，本文从测量的结果也与传统的测量结果不同，本文就Google App Engine的计算能力给出了测试结果：Google的免费账户提供了其承诺的计算力服务，但对于一些大规模计算的应用收到其计算力资源的限额，不能胜任。其结果并非传统的性能或流量、拓扑等具体值，而是针对用户业务在类型、效率以及成本方面给出的比较和建议。5总结与展望综上所述，本文针对云平台这个新的测量对象，采用与传统测量相异的测量方法，对云平台的计算能力、缓存能力和抖动情况等新的测量内容进行了的测度，根据测量结果，给出部署于云平台上的业务有关类型、性能和成本等方面的建议。然而，由于云平台本身的技术特点和复杂度，本文提出的测量方法仍较为简单，其测量结果也比较粗糙，因此下一步工作则是进一步研究不同云平台的技术特征，有针对性的提出新的测量方法，在测量目标上则应该开展对不同云平台的比较等，从而更好的为业务部署人员提供参考。参考文献1MerrillLynch. The CloudWars:$ 100+billion at stake.MerrilLynch research note, May 2008.2Gartner. Gartner Says Cloud ComputingW ill Be As Influ-entialAsE-business. Gartnerpress release, 26 June 2008.3IDC. IDC FindsCloud ComputingEntering Period ofAccel-eratingAdoption and Poised toCapture IT SpendingGrowth Over the Next Five Years. IDC press release, 20 October2008. 4MicroSoft.Cloud computing platform:Azure service platform overviewR.INSIGHT(MicroSoft),2008.5Amazon elastic compute cloud (amazon EC2) 6App Engine platform ht t p:/e lhumidor.blogspot .com/2009/04/ clojure-on-google-appengine.html.7Armbrust M,Fox A,Griffith R,et al.Above the clouds:A berkele view of cloud computingEB/OL.http:/www.eecs.berkeley.edu/Pubs/TechRpts/2009/EECS-2009-28.pdf.