【IT168资讯】Amazon EC2 云计算服务迈入正式版
Amazon 2008年10月23日宣布于2006年8月开始测试的Amazon Elastic Compute Cloud(EC2)云计算服务迈入正式版，Amazon亦在EC2提供服务质量协议(Service Level Agreement)以及新增支持微软Windows平台。
EC2原本仅提供Linux服务器的云计算服务，但现在开始新增对微软Windows平台的支持，在Windows Server 2003上执行EC2服务，因此可提供用户使用微软的AST.NET、ASP.NET AJAX、Silverlight及Internet Information Server等网络平台来部署应用程序。此外，EC2亦支持微软的SQL Server标准版与Express版本数据库。
Amazon说明，一般的Windows平台通常被用来执行网站及网络服务代管、高效能运算、数据处理、媒体解决、代管ASP.NET应用程序或是其它需要窗口软件的应用程序，使用窗口平台的EC2与使用其它操作系统的EC2服务类似，唯一的限制在于客户在一个可用区域(Availability Zone)中仅能采用窗口实例，不过未来可望取消该限制。
窗口平台的EC2收费标准为每运算小时0.125美元。Amazon计划在微软开发人员大会上展示支持窗口平台的EC2服务。
而服务质量协议则是用来担保EC2一年可具备99.95%的可用性，若Amazon未能达到此一标准，客户将可获得服务补偿。
Amazon亦打算在2009年发表新的EC2功能，包括用来均衡EC2不同实例中进出流量的负载平衡服务，以及可根据应用程序需求扩大或缩小EC2使用量的自动调整系统，可实时侦测不同实例所使用资源的云计算侦测系统，与新的云计算服务Web管理接口。
Amazon S3和EC2的性能报告 CSDN csjedi/译
Amazon于两年前发表云计算服务，当时云计算服务热潮才开始萌芽，但两年来各大业者相继投入开发并推出相关产品，成为近年来最夯的IT服务。
关于Amazon网络服务(AWS)云计算平台的一个最常被问起的就是其存储系统S3以及它的运算平台EC2的性能到底如何。通过一个完全运行在AWS云环境中的文件共享系统，HostedFTP.com基于其内部测试的性能数据创建了这份报告，其主要内容是讨论当在EC2实例和S3之间存取文件时所能获得的性能表现。
HostedFTP.com还将发表关于AWS超时的报告，同时每月我们还会对数据进行更新，从一个内部人员的角度向你传达AWS在增加容量和客户时的性能表现。
性能模型
当使用S3来存取文件的时候我们将性能表现分为两部分：一个是固定交易开销，它与文件大小无关;另一个是可变带宽开销，它与文件大小有关。换句话说，我们使用线性性能模型来测试S3和EC2之间的文件存取。
我们进行数据分析的目标是确定固定交易开销和可变带宽开销。
测试数据
下面是文件存取的测试数据，按照文件大小进行分组
数据表1：存储文件
分析
存储文件时的可变带宽开销在10到12MB/s之间，我们用线性回归法来得到固定交易开销。如下图所示：
该图显示存储文件时的固定交易开销大概是140ms。
数据表2：读取文件
分析
读取文件时的可变带宽开销仍然在10到12MB/s之间。与存储文件时不同的是，似乎看不出有固定交易开销。
结论
通过上面的分析我们可以得出如下结论：
1. 存取文件时的可变带宽开销都在10到12MB/s之间
2. 存储文件时的固定交易开销大概是140ms，读取文件时固定交易开销可忽略不计。
方法论
我们通过us-east-1a可用区域的大型EC2实体对从S3读取和存储文件所耗的时间进行了跟踪。我们使用JetS3t Java库通过轮流使用Commons HttpClient库来处理实际存储和读取的文件。当文件开始被存储到S3或从S3中读取时我们就开始计时。
我们分析了2月份随机抽取的总共50000个数据点(存储和读取)，这些点涵盖了一天中所有的时间段和一周所有的七天。
存在的局限和其它考虑
关于通过S3从大型EC2实体上所能获得的最大吞吐量(大概是50MB/s)在这里讨论。我们在这个测试里主动的调整了负载平衡，因为我们不想因为这个限制而给测试结果带来难以辨认的结果。
为了跟踪存取文件所耗的时间，我们使用了Java的System.currentTimeMillis()函数，该函数的说明文档中写到：
请注意该函数返回的时间的单位是毫秒，其计量尺度会因为所处的操作系统环境的不同而不同，也许会比实际值略大。例如许多操作系统都是以几十毫秒作为系统时间的计量单位。
因为我们所采用的大部分数据点都位于小尺寸文件，所以可能对结果有一定影响。
我们统计的时间不包括存取文件中发生的错误。
