项目越大越应该进行容量测试。2008年，英国西斯罗机场开放了新修建的航站楼，即5号航站楼。该航站楼项目耗资43亿英镑，但是没有比这个项目更庞大的项目了。但是5号航站楼开放首日的效果并不理想,包括人为因素和技术因素在内的多种状况导致了当天34架航班被取消，这成了接下来几日英国媒体竞相炒作的热门话题。容量不足的行李处理系统、痛苦等待的旅客等各种问题都是媒体关注的焦点。
云计算庞大的资源能否帮助我们在面对向西斯罗机场5号航站楼这样的大项目上实现更精确的容量需求模型设计呢？造成34架航班取消以及数千旅客痛苦愤怒的原因很多，但这对西斯罗机场的整体影响并不大，这也算是它的成功之处吧。而企业能否在云计算中要求拥有更好的容量管理工具呢？
检查容量
我希望在应用程序真正公开运行前就能知道程序所需的容量。就好像在飞机飞行前都要进行测试，避免飞上天空突然翅膀折断一样。因此我要在容量测试中搞清楚以下三个问题：
系统属性：在我的应用程序为客户服务前，应该列出所有可用资源，并找到系统负载的最大值。 产生综合负载：通过一个模拟器来模拟客户使用情况，模拟出日常客户对系统的使用负载。 监控系统变化：.当应用程序服务的客户量增加时，监控系统的负载变化情况。
此类工具除了可以测试系统容量，还可以测试其它任务，比如压力测试、性能监控，以及容量管理等。有些公司利用开源工具如multi-mechanize, Selenium以及JMeter 开发了适合自己的容量测试工具，其它公司则直接从云测试工具供应商，如Soasta, Loadstorm以及Cloudsleuth处购买相应的产品。而我当初曾使用过很多命令行工具，如lshw, top, tcpdump, df和ab。
检查整个技术堆栈
任何云应用都是建立在多个技术层之上的。
最顶层的是我们定制的业务应用程序和购置的办公应用程序。 虚拟机和操作系统支持程序。 运行在物理主机上的云供应商的操作系统和监管程序。 云供应商所拥有的最底层的硬件设备和网络设备。
云供应商所能控制的层级，即硬件、网络和超级监管程序等，是对用户隐藏以及用户无法测量的。一条锁链的强度，取决于锁链中最薄弱的那个环节，而在云架构中，这个链条很长环节很多，比如光纤、PDU、路由器、交换机、负载平衡、代理服务器等等。
AWS 控制台可以帮助我们监控CPU使用率，磁盘读写情况，网络流量情况等，而且这些功能都是免费的。虽然对于更高级的监控，这款免费工具无法提供，但是对于新手来说，这个工具已经够用了。对于更复杂的监控需求，AWS提供了Cloudwatch服务可以实现。
AWS监控窗口
技术堆栈的虚拟机层包括了磁盘、CPU和内存。而通过操作系统，这些设备都可以被监控，并且监控数据可以被系统监控工具获取并进行分析处理。而顶层，即应用层也是一样的。
云服务容量测量中存在的问题
我相信云服务供应商肯定会提供足够的冗余容量。不过这方面的具体数据我无法提供，因为没有哪个供应商会将自己的系统架构数据细节拿出来与大家分享。但是我相信未来两年，这些数据将会逐步透明，因为未来将会有越来越多的云服务供应商出现，企业向云平台迁移的速度也会达到高峰，服务水平将成为关键因素。未来云服务的价格将出现下滑，虚拟机与物理主机的比例将进一步提升。
对于虚拟机的测量方法，可能不如云供应商的物理主机测试的那么精准，因为虚拟机背后还有各种监管机制。这些监管程序会根据需求随时调整各个虚拟机的资源分配情况。这就好像是空管中心面对大量的飞机和数量有限的跑到所作的工作一样。
如果我的应用程序经常闲置，而另一个呼叫中心服务相当繁忙，那么CPU资源和网络带宽资源，肯定不会分配给我。如果我的存储需求极低，而某个用户需要存储几十个G的数据，那么物理磁盘空间肯定也是分配给那个用户的更多。而由于系统时钟是在虚拟的时间中工作，并不是实时的，因此由于监管程序导致的延迟、错误读取或其它小问题都会影响到我上述的对于云服务的测量方案。