导读：亚马逊云的性能实在是飘忽不定，时快时慢，有时甚至完全深不可测。
在开启云世界之前，让我们暂停一下，回忆下20世纪70年代的疯狂时光。那时候生产线科学难以理解，消费者每次购买商品都是一次赌博。汽车交易则更是十有八九如此，新车的质量万分不稳定，买者开始想知道在生产线上组装汽车的确定日期。
在周一组装的汽车据说危险较大，因为工人都“挂”了；而周五组装的汽车则更糟糕，因为每个人都已经开始思考周末的安排，无心工作。最偏执的买者甚至会详查日期，以确定当酒宴出现在周间，工人们都精神十足时，汽车能否出现在工厂。
由于更好的测试、对质量的更深投入，以及人们熬夜看体育比赛喝多了酒而大幅逃离制造等，被现在的购物者大量遗忘的情形跟过去的矛盾一模一样。现代工厂生产加工出完全相同的物品，近乎无趣。当现代电影表露出标准生产线时，电影通常是魅力自由机制杜绝的完美副本。
当我开始运行云计算机的基准测试时，我想到了20世纪70年代的那些回忆。尽管电脑以克隆般完美脱颖而出，类似“毫无灵魂”的形容词浮现在我脑海中，我开始发现，克隆的比喻可能并非是对那些可以从计算云上租赁的有效设备的最佳比喻。云设备也不完全一样，精密生产，就像完美匹配桌子的盒子那样，他们有点类似70年代的汽车。
在云计算企业的几个工程师抱怨了我对公共云调查的基准测试后，我开始学习这些。他们告诉我，这个测试并不足够成熟。
我的云测试结果没有一个明确的答案，只是关于用户可能体验到穿越虚拟之门的一份报告而已。就像消费者报考，我报名参加了某个企业的体验测试，提交了Java代码，然后写下测试结果。然而DaCapo基准测试套件在处理器独立（Java）和广泛收集常见服务器端代码（Jython，Tomcat）等上颇具优势，结果则是分散的。我认为，唯一的解决方法是去测试用户计划运行的每一个代码，因为这是确认哪种云设备会为他们的I/O、磁盘访问以及计算等特定组合提供最佳性能的唯一办法。
有一个工程师不喜欢这个办法。他问了一些一针见血的问题，问题的复杂度令人惊讶。精确办法是什么？测试依赖哪种操作系统？测试运行频率如何？会控制每天测试的时间段吗？
每天测试的时段？是的，工程师这么说。他确实像知道我们会不会对运行测试的时间段有所关注。确实，操作系统是不同性能表现的一大显著来源，使用最新的驱动和补丁也总是很有道理，但他也想知道测试的时间段。
这一点很新奇。CPU在短时间内上升的非常快，但他们以同样的速度在早上、中午和晚上进行计算，这对查看时间真的重要吗？是的，他说。换句话说，云设备比瑞士手表更像70年代的底特律生产线。
云科迈罗和克尔维特
为确认云到底会有怎样的七十二般变化，我选择了Amazon EC2。选择亚马逊因为亚马逊是行业领头羊之一，亚马逊云也是最为错综复杂的云之一，但最后的结论可能对其他的云来说也正确--他们玩的是同一个游戏。他们在创建一个超高速的电脑架，找到睿智的方法来与许多用户分享。即使销售文化让他看起来好像你只是购买了另外一台放在办公桌上的电脑，他也通常比你分时享用海滩公寓近得多。
从这一点来看，我应该暂停一下，撇开底特律的那些杞人忧天的典故和分时度假房产。一个亲切的云捍卫者可能会所，有时候你得到了你为之付出的东西，但往往你只是得到了幸运。如果哪天倒霉了，你最终可能与10个疯子共享1个CPU，他们试图通过疯狂使用处理器挖掘比特币成为富人；如果哪天幸运了，CPU为你带来了许多额外的免费周期。你最终可能与10个老奶奶们共享1个处理器，她们每周日才会刷新下网页，更新下教会公报的副本。换句话说，CPU瓶子不仅仅是半满的，但调酒师会用瓶子里剩下的酒灌满你的平底杯。