對速度的不滿在調(diào)優(yōu)的場景里占大多數(shù)，速度的不滿一般來說也是分兩種：

一種是對一個“體型”較大的任務(wù)執(zhí)行的時間過長不滿;

一種是對一個“體型”較小的任務(wù)的響應(yīng)速度過長不滿。

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

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

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

1、思路一：邏輯層面的優(yōu)化

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

還有的時候一個進(jìn)程可以分解為多個獨(dú)立作業(yè)和一個合并操作，那么這種情況下通?？梢試L試著多啟動幾個進(jìn)程或者線程，讓每個進(jìn)程或者線程處理整個作業(yè)的一部分，最后結(jié)束的時候做一個作業(yè)結(jié)果的“合并”操作，提高并行化，提高資源利用率。

這種應(yīng)用比較典型的就是Hadoop環(huán)境中的MapReduce程序，實際是在很多節(jié)點(diǎn)各啟動若干個Map進(jìn)程和Reduce進(jìn)程，讓它們在不同節(jié)點(diǎn)上操作，分?jǐn)侷O和CPU的資源壓力。在單臺服務(wù)器上也有類似的操作，如一個MySQL服務(wù)器進(jìn)程在接受一個SQL請求時，這個SQL不論請求多少個表，不論它有多少個不相干的子查詢，不論寫得有多“優(yōu)美”，它都只能在一個CPU內(nèi)核上一步一步地走下去。

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

2、思路二：容器層面的優(yōu)化

當(dāng)一臺或多臺服務(wù)器上有很多進(jìn)程，但是資源占用普遍比較低時，還可以考慮使用容器層面的優(yōu)化。

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

現(xiàn)在的阿里云、騰訊云、金山云、亞馬遜云等云產(chǎn)品服務(wù)商就是大規(guī)模使用了虛擬化技術(shù)，從而使得運(yùn)維成本大為降低。

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

3、思路三：存儲結(jié)構(gòu)層面的優(yōu)化

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

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

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

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

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

4、思路四：環(huán)節(jié)層面的優(yōu)化

環(huán)節(jié)層面的優(yōu)化是一個邊緣化的問題，因為這個層面上的優(yōu)化通常會涉及硬件資源以外的一些問題——換句話說，這一類問題在計算機(jī)的CPU、內(nèi)存、磁盤、網(wǎng)絡(luò)層面考慮可能還是不能解決的。

(1)虛擬機(jī)惹的禍

筆者幾年前在某500強(qiáng)企業(yè)的IT解決方案中心做顧問的時候，曾經(jīng)遇到過一個案例。

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

服務(wù)器在公司內(nèi)網(wǎng)，內(nèi)網(wǎng)帶寬又基本都是1Gbps的光纖到樓層，樓層內(nèi)部又都是100Mbps的以太網(wǎng)。所以從這個層面上看這種頁面的延遲沒有道理，而其他項目組在配置基本相當(dāng)?shù)姆?wù)器環(huán)境和終端環(huán)境，打開頁面時間都是1秒以內(nèi)。

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

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

(2)CDN是個好東西

除了剛剛這個例子以外，平時也能見到很多從環(huán)節(jié)層面進(jìn)行優(yōu)化的例子。最常見的就是CDN技術(shù)。

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

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

互聯(lián)網(wǎng)是一個非常復(fù)雜的東西，不僅是拓?fù)浣Y(jié)構(gòu)復(fù)雜，其中不同的交換設(shè)備有著不同的交換策略，是一個分布式的自協(xié)調(diào)的連通系統(tǒng)。不同運(yùn)營商之間也會由于技術(shù)性的或者非技術(shù)性的問題引發(fā)跨網(wǎng)(跨運(yùn)營商)的帶寬變窄問題。為了解決這種問題，我們不僅僅會用到CDN技術(shù)，還需要使用一種叫BGP雙線/多線機(jī)房的技術(shù)來進(jìn)行網(wǎng)絡(luò)加速。

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

5、資源不足

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

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

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