當面對一個性能擴展問題時，很多人往往通過加大投資，購買硬件的方式來解決，期望找到一顆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