對速度的不滿在調優的場景里占大多數，速度的不滿一般來說也是分兩種：

一種是對一個“體型”較大的任務執行的時間過長不滿;

一種是對一個“體型”較小的任務的響應速度過長不滿。

這兩種不滿看上去都是一樣的速度問題，但是思路不完全一樣。一般來說，在做這類優化之前先要做一件事，就是判斷一下究竟是資源不足，還是資源分配不合理。

常見的場景可能有以下這些：例如，一個進程在服務器上運行，但是速度確實比期望的慢，而CPU和磁盤的帶寬卻大量閑置，這種情況下很顯然是資源配置不合理。

因為資源不是不夠，而是由于線程調度，或者算法，或者其他一些原因沒有被利用上。這種情況下估計你去申請購買新機器，如果老板花的確實是自己的錢的話十有八九是不會給你批的，相信我。

1、思路一：邏輯層面的優化

在服務器上跑的程序，尤其是Batch通常是彼此之間獨立的。這種情況下，其實是可以考慮讓它們同時來執行，充分利用CPU和內存的資源。但是也要注意，要確認這種變化給磁盤帶來的IO增加不會讓它成為系統的瓶頸。這就是進程級別的并發。

還有的時候一個進程可以分解為多個獨立作業和一個合并操作，那么這種情況下通常可以嘗試著多啟動幾個進程或者線程，讓每個進程或者線程處理整個作業的一部分，最后結束的時候做一個作業結果的“合并”操作，提高并行化，提高資源利用率。

這種應用比較典型的就是Hadoop環境中的MapReduce程序，實際是在很多節點各啟動若干個Map進程和Reduce進程，讓它們在不同節點上操作，分攤IO和CPU的資源壓力。在單臺服務器上也有類似的操作，如一個MySQL服務器進程在接受一個SQL請求時，這個SQL不論請求多少個表，不論它有多少個不相干的子查詢，不論寫得有多“優美”，它都只能在一個CPU內核上一步一步地走下去。

所以，如果采用MySQL環境做關聯分析，就只能把一個SQL中的兩個獨立子查詢放到兩個或者更多的線程(進程)里去做請求，再用一個監控線程(進程)觀察結果，最后做連接查詢。有必要的話可以使用Memory內存視圖的Hash索引進行速度優化。

2、思路二：容器層面的優化

當一臺或多臺服務器上有很多進程，但是資源占用普遍比較低時，還可以考慮使用容器層面的優化。

可以使用KVM或者Docker這樣的容器把服務器資源劃分成多個虛擬的服務器資源。這種情況下，原本在多個服務器的少量負載經過遷移會合起來加載在一個服務器上，而節省出來的服務器資源可以用來做其他的服務，在硬件的成本上會有一大筆節省。

現在的阿里云、騰訊云、金山云、亞馬遜云等云產品服務商就是大規模使用了虛擬化技術，從而使得運維成本大為降低。

雖然容器層面的優化對于直接減少程序運行的時間作用較為間接，但在龐大的系統內提高硬件整體的使用效率還是非常有好處的。

3、思路三：存儲結構層面的優化

目前在服務器普遍配置了RAID10磁盤陣列以后，磁盤IO在硬件層面進一步并行化的余地越來越小了。那么還有沒有其他的辦法可以對IO層面進行優化呢?有的。

例如，為了緩存一些數據做迭代運算，磁盤發生非常頻繁的讀寫，每次幾個GB(量比較小，至少內存能夠承載)，但是一次處理可能要讀寫數百次，這樣會大量占用磁盤IO。這種情況下，不妨嘗試在內存中虛擬或者劃分出一個獨立的空間，以供做IO使用。這樣把CPU和磁盤之間的IO轉化成為CPU和內存之間的IO，這種效率的提升可能是數千倍的。

另外，磁盤在做IO的過程中，是不是掃描了一些本可以不掃描的磁盤塊?解決這種問題有很多成熟的辦法。

在數據倉庫里使用列式存儲，從本質來講也是用這種方法來規避沒必要掃描的數據塊被掃描。表分區(Table Partitioning)、索引(Index)，這兩種技術同樣是為了解決數據查找中沒必要掃描的數據塊被訪問而帶來的IO效率下降問題。

資源分配不合理的情況比較好解決，就是找出在系統里CPU、內存、磁盤、網絡中，哪些資源被大量閑置，如果利用起來能否提高并行性，基本就是這樣一種思路。

4、思路四：環節層面的優化

環節層面的優化是一個邊緣化的問題，因為這個層面上的優化通常會涉及硬件資源以外的一些問題——換句話說，這一類問題在計算機的CPU、內存、磁盤、網絡層面考慮可能還是不能解決的。

(1)虛擬機惹的禍

筆者幾年前在某500強企業的IT解決方案中心做顧問的時候，曾經遇到過一個案例。

這個案例從技術層面來說就是一個ERP系統頁面請求速度太慢的問題，大概需要2到3秒時間才能把一個頁面的數據完全加載完畢。不管2到3秒這個速度是不是夠快，是不是比平時訪問電商網頁或者在線論壇的速度快，對于一個對效率要求很苛刻的500強企業來說，這是一件不能容忍的事情。況且，頁面所訪問的服務器也是DELL提供的很新的技術方案，48個CPU內核，192GB內存。

服務器在公司內網，內網帶寬又基本都是1Gbps的光纖到樓層，樓層內部又都是100Mbps的以太網。所以從這個層面上看這種頁面的延遲沒有道理，而其他項目組在配置基本相當的服務器環境和終端環境，打開頁面時間都是1秒以內。

但是很快就發現了問題所在，這個ERP系統的頁面是使用Silverlight制作的。Silverlight是微軟出品的一種跨服務器跨平臺的插件，主要目的是解決瀏覽器上的流媒體和交互豐富性的問題，基本可以認為是Adobe Flash的替代者。然而這種技術框架有一個天生的問題就是慢，因為它調用的是微軟.NET虛擬機的資源，而虛擬機本身的運行機制就是一種多層間接調用的架構，指令不是直接下達到CPU上，而是經過虛擬機，由虛擬機調度線程再發送到CPU。在一次HTTP請求的過程中，有幾百個指令會以這種方式傳遞給CPU，延遲是顯而易見的。

最后為了贏得這1秒多的時間，不得不推翻了整個項目的架構部分，采用HTML4+CSS2的方式。立竿見影，延遲瞬間就壓縮到1秒以內了。但是代價是犧牲了一些交互上的豐富性和美觀性，那個時候HTML5和CSS3還不成熟，還不能作為成熟的技術方案，所以說現在用HTML5和CSS3的程序員們真是趕上好時候了。

(2)CDN是個好東西

除了剛剛這個例子以外，平時也能見到很多從環節層面進行優化的例子。最常見的就是CDN技術。

CDN技術是一種近幾年非常火的技術，全稱是Content Delivery Network，內容分發網絡。CDN應該說是一套完整的網絡加速解決方案，包括分布式存儲、負載均衡、網絡請求的重定向和內容管理等多個技術環節部分。對于用戶在網頁上請求圖片加載慢，或者文件下載慢等非本地帶寬過小帶來的數據下載問題能有很好的改善作用。

例如，當一個網站使用了CDN技術對網頁資源進行加速的策略開啟后，這些資源就會通過CDN提供商的分發策略分發到很多的緩存服務器上去。當用戶進行該網站的訪問時，這些資源引用的地址會自動指向這個離得最“近”，訪問最快的緩存服務器節點上去，這樣就能使資源下載加速了。

互聯網是一個非常復雜的東西，不僅是拓撲結構復雜，其中不同的交換設備有著不同的交換策略，是一個分布式的自協調的連通系統。不同運營商之間也會由于技術性的或者非技術性的問題引發跨網(跨運營商)的帶寬變窄問題。為了解決這種問題，我們不僅僅會用到CDN技術，還需要使用一種叫BGP雙線/多線機房的技術來進行網絡加速。

BGP(Border Gateway Protocol，邊界網關協議)是一種在TCP協議上運行的自治系統之間動態交換路由信息的路由協議。啟用BGP技術的機房一般稱作BGP機房，服務器租用商或提供商通過技術的手段，實現不同運營商能共同訪問一個IP，并且不同運營商之間都能以最快的速度訪問這個IP地址。把服務器放在BGP機房給用戶帶來的好處就是，在BGP機房基本可以不考慮不同的用戶跨網訪問服務器會因運營商網絡不同而產生的“帶寬歧視”問題。

5、資源不足

資源不足的情況通常比較麻煩，因為如果觀察到服務器上的CPU、磁盤IO、網絡IO都非常繁忙，要想辦法先排除是業務邏輯上設計的疏漏導致的不合理或者意外的資源請求太多，還是“真的”資源不夠。

如果是由于一些疏漏導致的資源請求過于集中，那么通過debug或者優化業務邏輯，還是能夠獲解的。但是如果不是這些問題，那就是資源確實比客觀真實的需求少了。典型的例子就是，在保存日志的情況下，業務要求無損永久存檔，但是即便在啟用壓縮且不留冗余的情況下，還是很快把磁盤填滿，那就是典型的磁盤資源不足了。

總之，還是要先用一些辦法確定資源分配究竟是不足還是不合理，再用“低成本”的資源換取“高成本”的資源。