当面对一个性能扩展问题时，很多人往往通过加大投资，购买硬件的方式来解决，期望找到一颗silver bullet，但是大多数情况下，结果没有达到预期，本文作者是Rackspace的主任兼首席工程师 Aaron Sullivan，他认为在面对性能提升问题时，不能冒然的加大投资，寻找silver bullet，而是应该有条不紊的寻找差距，准备一个全面的方案，包括所涉及到的应用程序、基础设施、团队，另外，你需要注意序列化，它是anti-silver bullet。
以下为译文：
我们都喜欢一个silver bullet（往往被比作药到病除的良方）。在过去的几年里，如果总结我在Rackspace公司里看到客户们使用SSD的经验，不外乎是两种情况。第一种情况是一个silver bullet——增加SSD创建了一个近乎奇迹般的性能改进。第二种情况是（最常见的）这颗bullet被射向了一个错误的目标——结果远远低于预期值。
在第二种情况中，文件系统、数据存储及进程经常变得不稳定。然而，这些令人泄气的结果通常由客户们错误的加速方式导致的。
导致令人失望的SSD结果的关键因素就是序列化，这是个普遍现象。尽管事实上大多数服务器拥有并行处理器（如多核、 multi-socket）、并行内存系统（例如NUMA，多通道内存控制器）、并行存储系统（如磁盘分条，NAND）和多线程软件，事务处理仍然必须按一定顺序执行。因此你软件和系统设计中的一些部分，需要循序渐进的进行。从步骤1到步骤2，然后到步骤3，这就是序列化。
不能仅仅因为软件或系统内部固有的并行设计，就认为这些部分不需要序列化。有些系统中的一部分能够同时接收和处理成千上万条离散请求，但却要等待其他序列化部分。软件开发人员和系统架构师已经能用各种各样的方法来处理这个问题。多层web体系架构的提出，从某种程度上来说就是针对这个问题的。最近，数据库分片也有助于解决这个问题。但是，使系统中的一些部分并行并不意味着所有部分都是并行的。此外，即使设计时着重强调了并行性，也不可能杜绝序列操作的存在。
这个问题到底可以追溯到多远？其实，在并行计算出现之初就已经出现了，至少可追溯到1960年代。在过去的十年中，在并行内存系统、分布式数据库和存储系统、多核CPU、GPU等上都做了特别的改进。这些改进往往紧随着一个新的硬件革新之后。因此，以SSD为例，改进并没有集中在SSD本身。我们全部的存储软件栈的概念都在改变，但是，同样的，你将看到，即使我们整个存储堆栈比今天快几千倍，序列化仍然是一个难题。我们总是想各种办法解决这个问题，但我们很少能让它消失。
并行化和序列化
下表提供了一个服务器和存储设备的并行和序列化示例，从软件应用程序到底下的存储介质。进程中的每个步骤都可以支持复杂的队列和并行机制。即便如此，对于任何给定的事务和群集事务，需要的步骤仍然必须要顺序执行。时间积累自每个步骤。
这一系列的步骤呈现的是一个服务器中的一个简化的，小的组件，在本例中是存储组件。但在工作中，一个服务器中还有各种各样的其他组件。某些其他组件，如一个数据库应用程序，往往是链式累积存储。我们可以针对数据库应用程序创建一系列类似步骤，数据库应用程序利用系统存储，我们可以将两个表合并。我们可以为web服务、缓存服务等构建类似的宏观层模型，许多（或全部）这些组件连接在一起来完成一个事务处理。
如上所述，每个事务涉及的组件增加了累计的时间基准。提高每个部分都需要一套不同的工具、方法和技巧。通常，当我们无法解决性能问题时，相对容易的方法是通过加大投资就可以获得相应的解决方案。我们买更多的服务器、更多的处理器、更快的磁盘、更快的网卡和交换机等等。有时，我们会幸运得到silver bullet。但是当我们不够幸运时，它会是什么样子呢。
假设我们已经构建了下一个杀手级应用，它变得越来越受欢迎，突破负载极限。以我们增长的速度，在3个月内，我们将需要将性能提升10倍。我们该怎么做？
我们可能会把我们的系统复制到世界各地的重要战略位置，以减少网络延迟，我们可以将我们所有的服务器和交换机从1 Gb /秒升级到10 Gb /秒。我们可能将SSD添加到我们系统的各个部分。假设这些改进减少了70%相关网络处理时间以及99.9%（a~ 1000 倍改善）的存储时间。但在我们的应用程序中，这些只让我们的性能提高了83%。这甚至还达不到原来的双倍性能，我们已经做了大量投资。此时，你可能会想，“我们使存储提速那么多，怎么在图上如此不明显。为什么1000倍的存储性能改进和庞大的网络开销只让我们加速了83%？”
答案在图中，10倍改进总体需要累计执行时间（图表的左纵轴）从3.0到0.3。
获得10倍的改进需要将我们整个环境做出巨大改进。我们进一步假设网络不能加快。下图所示的是其他因素改变及合成之后达到的10倍性能提升的例子。
注意，我们通过四个步骤来实现这种显著的性能提升。首先，我们在web层和缓存层做了一个可测量的改进，使它速度加倍。第二，我们对数据库层也做了同样的改进，也使它速度加倍。这让我们得到了一个3.16 倍的总体性能改进。由于这还不够，第三步：我们也重新设计了整个平台，并通过努力改善了所有的这三个平台，使它们比基线提升3倍的速度。这使我们的性能提高4.2倍。
那么怎样才能达到的10倍加速吗？假设我们聘请了一群技术大牛来帮助我们来完成此次改进……
因此，第四步，技术大牛带来了一些令人惊异的新技术、代码、工具、和理念。我们使web、缓存和数据库层得到了比原先设计时20倍的加速。我们还利用SSD做了另一个1000倍的改进。他们没有透露更多的内容，其中一个人信誓旦旦的说，我们需要的就是更快的SSD（有时这些技术大牛也是silver-bullet的受害者）。最后，我们并没有达到10倍，除非我们靠的足够近。
现在，让我们回到现实。如果我们真的需要这种全面的大规模的速度提升，还是先让我们考虑一下自己的开发团队是否能满足这些惊人的要求。我们需要10倍的开发者技能吗？10倍的提高来自于一个人吗？需要10倍员工吗？10倍的测试资源吗？这是不现实的，至少不是马上需要。在合适的地方、合适的时间进行投资是非常重要的。
在这一过程中，我们需要有条不紊地分析我们的差距，找到最谨慎的方式来弥补。根据我的经验，谨慎并不激动人心，但它非常有效。
当面对一个扩展的问题时，很多人常常以为他们可以通过添加硬件的方式来解决它——这正是虚构的silver bullet。如果你认为有一个简单的解决方案，碰巧有一些SSD，无论如何，不妨试试! 如果还不够的，准备一个全面的方案。包括所涉及到的你的应用程序、基础设施、团队。一定要保持一颗开诚布公的心态，你可能需要全面的改进来达到你的目标。你觉得可以的时候你可以雇佣超级明星，你需要注意序列化，它是anti-silver bullet。
原文链接： Performance At Scale: SSDs, Silver Bullets, And Serialization