云应用程序的容量测试

项目越大越应该进行容量测试。2008年，英国西斯罗机场开放了新修建的航站楼，即5号航站楼。该航站楼项目耗资43亿英镑，但是没有比这个项目更庞大的项目了。但是5号航站楼开放首日的效果并不理想，包括人为因素和技术因素在内的多种状况导致了当天34架航班被取消，这成了接下来几日英国媒体竞相炒作的热门话题。容量不足的行李处理系统、痛苦等待的旅客等各种问题都是媒体关注的焦点。

云计算庞大的资源能否帮助我们在面对向西斯罗机场5号航站楼这样的大项目上实现更精确的容量需求模型设计呢?造成34架航班取消以及数千旅客痛苦愤怒的原因很多，但这对西斯罗机场的整体影响并不大，这也算是它的成功之处吧。而企业能否在云计算中要求拥有更好的容量管理工具呢?

检查容量

我希望在应用程序真正公开运行前就能知道程序所需的容量。就好像在飞机飞行前都要进行测试，避免飞上天空突然翅膀折断一样。因此我要在容量测试中搞清楚以下三个问题：

系统属性：在我的应用程序为客户服务前，应该列出所有可用资源，并找到系统负载的最大值。

产生综合负载：通过一个模拟器来模拟客户使用情况，模拟出日常客户对系统的使用负载。

监控系统变化：。当应用程序服务的客户量增加时，监控系统的负载变化情况。

此类工具除了可以测试系统容量，还可以测试其它任务，比如压力测试、性能监控，以及容量管理等。有些公司利用开源工具如multi-mechanize, Selenium以及JMeter 开发了适合自己的容量测试工具，其它公司则直接从云测试工具供应商，如Soasta, Loadstorm以及Cloudsleuth处购买相应的产品。而我当初曾使用过很多命令行工具，如lshw, top, tcpdump, df和ab。

检查整个技术堆栈

任何云应用都是建立在多个技术层之上的。

最顶层的是我们定制的业务应用程序和购置的办公应用程序。

虚拟机和操作系统支持程序。

运行在物理主机上的云供应商的操作系统和监管程序。

云供应商所拥有的最底层的硬件设备和网络设备。

云供应商所能控制的层级，即硬件、网络和超级监管程序等，是对用户隐藏以及用户无法测量的。一条锁链的强度，取决于锁链中最薄弱的那个环节，而在云架构中，这个链条很长环节很多，比如光纤、PDU、路由器、交换机、负载平衡、代理服务器等等。

微信扫一扫实时了解行业动态

微信扫一扫分享本文给好友