[ASP.NET C#] 性能調教攻略

Reference：http://coolshell.cn/articles/7490.html

關於性能優化這是一個比較大的話題，在《由12306.cn談談網站性能技術》中我從業務和設計上說過一些可用的技術以及那些技術的優缺點，今天，想從一些技術細節上談談性能優化，主要是一些代碼級別的技術和方法。本文的東西是我的一些經驗和知識，並不一定全對，希望大家指正和補充。

在開始這篇文章之前，大家可以移步去看一下酷殼以前發表的《代碼優化概要》，這篇文章基本上告訴你——要進行優化，先得找到性能瓶頸！ 但是在講如何定位系統性能瓶勁之前，請讓我講一下系統性能的定義和測試，因為沒有這兩件事，後面的定位和優化無從談起。

一、系統性能定義

讓我們先來說說如何什麼是系統性能。這個定義非常關鍵，如果我們不清楚什麼是系統性能，那麼我們將無法定位之。我見過很多朋友會覺得這很容易，但是仔細一問，其實他們並沒有一個比較系統的方法，所以，在這裡我想告訴大家如何系統地來定位性能。 總體來說，系統性能就是兩個事：

1.    Throughput ，輸送量。也就是每秒鐘可以處理的請求數，任務數。

2.    Latency， 系統延遲。也就是系統在處理一個請求或一個任務時的延遲。

一般來說，一個系統的性能受到這兩個條件的約束，缺一不可。比如，我的系統可以頂得住一百萬的併發，但是系統的延遲是2分鐘以上，那麼，這個一百萬的負載毫無意義。系統延遲很短，但是輸送量很低，同樣沒有意義。所以，一個好的系統的性能測試必然受到這兩個條件的同時作用。 有經驗的朋友一定知道，這兩個東西的一些關係：

·         Throughput越大，Latency會越差。因為請求量過大，系統太繁忙，所以回應速度自然會低。

·         Latency越好，能支持的Throughput就會越高。因為Latency短說明處理速度快，於是就可以處理更多的請求。

二、系統性能測試

經過上述的說明，我們知道要測試系統的性能，需要我們收集系統的Throughput和Latency這兩個值。

·         首先，需要定義Latency這個值，比如說，對於網站系統回應時間必需是5秒以內（對於某些即時系統可能需要定義的更短，比如5ms以內，這個更根據不同的業務來定義）

·         其次，開發性能測試工具，一個工具用來製造高強度的Throughput，另一個工具用來測量Latency。對於第一個工具，你可以參考一下“十個免費的Web壓力測試工具”，關於如何測量Latency，你可以在代碼中測量，但是這樣會影響程式的執行，而且只能測試到程式內部的Latency，真正的Latency是整個系統都算上，包括作業系統和網路的延時，你可以使用Wireshark來抓網路包來測量。這兩個工具具體怎麼做，這個還請大家自己思考去了。

·         最後，開始性能測試。你需要不斷地提升測試的Throughput，然後觀察系統的負載情況，如果系統頂得住，那就觀察Latency的值。這樣，你就可以找到系統的最大負載，並且你可以知道系統的回應延時是多少。

再多說一些，

·         關於Latency，如果輸送量很少，這個值估計會非常穩定，當輸送量越來越大時，系統的Latency會出現非常劇烈的抖動，所以，我們在測量Latency的時候，我們需要注意到Latency的分佈，也就是說，有百分之幾的在我們允許的範圍，有百分之幾的超出了，有百分之幾的完全不可接受。也許，平均下來的Latency達標了，但是其中僅有50%的達到了我們可接受的範圍。那也沒有意義。

·         關於性能測試，我們還需要定義一個時間段。比如：在某個輸送量上持續15分鐘。因為當負載到達的時候，系統會變得不穩定，當過了一兩分鐘後，系統才會穩定。另外，也有可能是，你的系統在這個負載下前幾分鐘還表現正常，然後就不穩定了，甚至垮了。所以，需要這麼一段時間。這個值，我們叫做峰值極限。

·         性能測試還需要做Soak Test，也就是在某個輸送量下，系統可以持續跑一周甚至更長。這個值，我們叫做系統的正常運行的負載極限。

性能測試有很多很複要的東西，比如：burst test等。 這裡不能一一詳述，這裡只說了一些和性能調優相關的東西。總之，性能測試是一細活和累活。

三、定位性能瓶頸

有了上面的鋪墊，我們就可以測試到到系統的性能了，再調優之前，我們先來說說如何找到性能的瓶頸。我見過很多朋友會覺得這很容易，但是仔細一問，其實他們並沒有一個比較系統的方法。

3.1）查看作業系統負載

首先，當我們系統有問題的時候，我們不要急於去調查我們代碼，這個毫無意義。我們首要需要看的是作業系統的報告。看看作業系統的CPU利用率，看看記憶體使用率，看看作業系統的IO，還有網路的IO，網路連結數，等等。Windows下的perfmon是一個很不錯的工具，Linux下也有很多相關的命令和工具，比如：SystemTap，LatencyTOP，vmstat, sar, iostat, top, tcpdump等等 。通過觀察這些資料，我們就可以知道我們的軟體的性能基本上出在哪裡。比如：

1）先看CPU利用率，如果CPU利用率不高，但是系統的Throughput和Latency上不去了，這說明我們的程式並沒有忙於計算，而是忙於別的一些事，比如IO。（另外，CPU的利用率還要看內核態的和用戶態的，內核態的一上去了，整個系統的性能就下來了。而對於多核CPU來說，CPU 0 是相當關鍵的，如果CPU 0的負載高，那麼會影響其它核的性能，因為CPU各核間是需要有調度的，這靠CPU0完成）

2）然後，我們可以看一下IO大不大，IO和CPU一般是反著來的，CPU利用率高則IO不大，IO大則CPU就小。關於IO，我們要看三個事，一個是磁片檔IO，一個是驅動程式的IO（如：網卡），一個是記憶體換頁率。這三個事都會影響系統性能。

3）然後，查看一下網路頻寬使用情況，在Linux下，你可以使用iftop, iptraf, ntop, tcpdump這些命令來查看。或是用Wireshark來查看。

4）如果CPU不高，IO不高，記憶體使用不高，網路頻寬使用不高。但是系統的性能上不去。這說明你的程式有問題，比如，你的程式被阻塞了。可能是因為等那個鎖，可能是因為等某個資源，或者是在切換上下文。

通過瞭解作業系統的性能，我們才知道性能的問題，比如：頻寬不夠，記憶體不夠，TCP緩衝區不夠，等等，很多時候，不需要調整程式的，只需要調整一下硬體或作業系統的配置就可以了。

3.2）使用Profiler測試

接下來，我們需要使用性能檢測工具，也就是使用某個Profiler來差看一下我們程式的運行性能。如：Java的JProfiler/TPTP/CodePro Profiler，GNU的gprof，IBM的PurifyPlus，Intel的VTune，AMD的CodeAnalyst，還有Linux下的OProfile/perf，後面兩個可以讓你對你的代碼優化到CPU的微指令級別，如果你關心CPU的L1/L2的緩存調優，那麼你需要考慮一下使用VTune。 使用這些Profiler工具，可以讓你程式中各個模組函數甚至指令的很多東西，如：運行的時間 ，調用的次數，CPU的利用率，等等。這些東西對我們來說非常有用。

我們重點觀察執行時間最多，調用次數最多的那些函數和指令。這裡注意一下，對於調用次數多但是時間很短的函數，你可能只需要輕微優化一下，你的性能就上去了（比如：某函數一秒種被調用100萬次，你想想如果你讓這個函數提高0.01毫秒的時間 ，這會給你帶來多大的性能）

使用Profiler有個問題我們需要注意一下，因為Profiler會讓你的程式運行的性能變低，像PurifyPlus這樣的工具會在你的代碼中插入很多代碼，會導致你的程式運行效率變低，從而沒發測試出在高輸送量下的系統的性能，對此，一般有兩個方法來定位系統瓶頸：

1）在你的代碼中自己做統計，使用微秒級的計時器和函式呼叫計算器，每隔10秒把統計log到檔中。

2）分段注釋你的代碼塊，讓一些函數空轉，做Hard Code的Mock，然後再測試一下系統的Throughput和Latency是否有質的變化，如果有，那麼被注釋的函數就是性能瓶頸，再在這個函數體內注釋代碼，直到找到最耗性能的語句。

最後再說一點，對於性能測試，不同的Throughput會出現不同的測試結果，不同的測試資料也會有不同的測試結果。所以，用於性能測試的資料非常重要，性能測試中，我們需要觀測試不同Throughput的結果。

四、常見的系統瓶頸

下面這些東西是我所經歷過的一些問題，也許並不全，也許並不對，大家可以補充指正，我純屬抛磚引玉。關於系統架構方面的性能調優，大家可移步看一下《由12306.cn談談網站性能技術》，關於Web方面的一些性能調優的東西，大家可以看看《Web開發中需要瞭解的東西》一文中的性能一章。我在這裡就不再說設計和架構上的東西了。

一般來說，性能優化也就是下面的幾個策略：

·         用空間換時間。各種cache如CPU L1/L2/RAM到硬碟，都是用空間來換時間的策略。這樣策略基本上是把計算的過程一步一步的保存或緩存下來，這樣就不用每次用的時候都要再計算一遍，比如資料緩衝，CDN，等。這樣的策略還表現為冗餘數據，比如資料鏡象，負載均衡什麼的。

·         用時間換空間。有時候，少量的空間可能性能會更好，比如網路傳輸，如果有一些壓縮資料的演算法（如前些天說的“Huffman 編碼壓縮演算法” 和 “rsync 的核心演算法”），這樣的演算法其實很耗時，但是因為瓶頸在網路傳輸，所以用時間來換空間反而能省時間。

·         簡化代碼。最高效的程式就是不執行任何代碼的程式，所以，代碼越少性能就越高。關於代碼級優化的技術大學裡的教科書有很多示例了。如：減少迴圈的層數，減少遞迴，在迴圈中少聲明變數，少做分配和釋放記憶體的操作，儘量把循環體內的運算式抽到迴圈外，條件表達的中的多個條件判斷的次序，儘量在程式啟動時把一些東西準備好，注意函式呼叫的開銷（棧上開銷），注意物件導向語言中臨時物件的開銷，小心使用異常（不要用異常來檢查一些可接受可忽略並經常發生的錯誤），…… 等等，等等，這連東西需要我們非常瞭解程式設計語言和常用的庫。

·         並行處理。如果CPU只有一個核，你要玩多進程，多執行緒，對於計算密集型的軟體會反而更慢（因為作業系統調度和切換開銷很大），CPU的核多了才能真正體現出多進程多執行緒的優勢。並行處理需要我們的程式有Scalability，不能水準或垂直擴展的程式無法進行並行處理。從架構上來說，這表再為——是否可以做到不改代碼只是加加機器就可以完成性能提升？

總之，根據2：8原則來說，20%的代碼耗了你80%的性能，找到那20%的代碼，你就可以優化那80%的性能。 下面的一些東西都是我的一些經驗，我只例舉了一些最有價值的性能調優的的方法，供你參考，也歡迎補充。

4.1）演算法調優。演算法非常重要，好的演算法會有更好的性能。舉幾個我經歷過的項目的例子，大家可以感覺一下。

·         一個是過濾演算法，系統需要對收到的請求做過濾，我們把可以被filter in/out的東西配置在了一個檔中，原有的過濾演算法是遍歷過濾配置，後來，我們找到了一種方法可以對這個過濾配置進行排序，這樣就可以用二分折半的方法來過濾，系統性能增加了50%。

·         一個是雜湊演算法。計算雜湊演算法的函數並不高效，一方面是計算太費時，另一方面是碰撞太高，碰撞高了就跟單向鏈表一個性能（可參看Hash Collision DoS 問題）。我們知道，演算法都是和需要處理的資料很有關係的，就算是被大家所嘲笑的“冒泡排序”在某些情況下（大多數資料是排好序的）其效率會高於所有的排序演算法。雜湊演算法也一樣，廣為人知的雜湊演算法都是用英文字典做測試，但是我們的業務在資料有其特殊性，所以，對於還需要根據自己的資料來挑選適合的雜湊演算法。對於我以前的一個專案，公司內某牛人給我發來了一個雜湊演算法，結果讓我們的系統性能上升了150%。（關於各種雜湊演算法，你一定要看看StackExchange上的這篇關於各種hash演算法的文章 ）

·         分而治之和預處理。以前有一個程式為了生成月報表，每次都需要計算很長的時間，有時候需要花將近一整天的時間。於是我們把我們找到了一種方法可以把這個演算法發成增量式的，也就是說我每天都把當天的資料計算好了後和前一天的報表合併，這樣可以大大的節省計算時間，每天的資料計算量只需要20分鐘，但是如果我要算整個月的，系統則需要10個小時以上（SQL語句在大資料量面前性能成級數性下降）。這種分而治之的思路在大資料面前對性能有很説明，就像merge排序一樣。SQL語句和資料庫的性能優化也是這一策略，如：使用嵌模式的Select而不是笛卡爾積的Select，使用視圖，等等。

4.2）代碼調優。從我的經驗上來說，代碼上的調優有下面這幾點：

·         字串操作。這是最費系統性能的事了，無論是strcpy, strcat還是strlen，最需要注意的是字串子串匹配。所以，能用整型最好用整型。舉幾個例子，第一個例子是N年前做銀行的時候，我的同事喜歡把日期存成字串（如：2012-05-29 08:30:02），我勒個去，一個select  where between語句相當耗時。另一個例子是，我以前有個同事把一些狀態碼用字串來處理，他的理由是，這樣可以在介面上直接顯示，後來性能調優的時候，我把這些狀態碼全改成整型，然後用位元操作查狀態，因為有一個每秒鐘被調用了150K次的函數裡面有三處需要檢查狀態，經過改善以後，整個系統的性能上升了30%左右。還有一個例子是，我以前從事的某個產品程式設計規範中有一條是要在每個函數中把函數名定義出來，如：const char fname[]=”functionName()”, 這是為了好打日誌，但是為什麼不聲明成 static類型的呢？

·         多執行緒調優。有人說，thread is evil，這個對於系統性能在某些時候是個問題。因為多執行緒瓶頸就在於互斥和同步的鎖上，以及執行緒上下文切換的成本，怎麼樣的少用鎖或不用鎖是根本（比如：多版本併發控制(MVCC)在分散式系統中的應用 中說的樂觀鎖可以解決性能問題），此外，還有讀寫鎖也可以解決大多數是讀操作的併發的性能問題。這裡多說一點在C++中，我們可能會使用執行緒安全的智慧指標AutoPtr或是別的一些容器，只要是執行緒安全的，其不管三七二十一都要上鎖，上鎖是個成本很高的操作，使用AutoPtr會讓我們的系統性能下降得很快，如果你可以保證不會有執行緒併發問題，那麼你應該不要用AutoPtr。我記得我上次我們同事去掉智慧指標的引用計數，讓系統性能提升了50%以上。對於Java物件的引用計數，如果我猜的沒錯的話，到處都是鎖，所以，Java的性能問題一直是個問題。另外，執行緒不是越多越好，執行緒間的調度和上下文切換也是很誇張的事，盡可能的在一個執行緒裡幹，盡可能的不要同步執行緒。這會讓你有很多的性能。

·         記憶體分配。不要小看程式的記憶體分配。malloc/realloc/calloc這樣的系統調非常耗時，尤其是當記憶體出現碎片的時候。我以前的公司出過這樣一個問題——在用戶的網站上，我們的程式有一天不回應了，用GDB跟進去一看，系統hang在了malloc操作上，20秒都沒有返回，重啟一些系統就好了。這就是記憶體碎片的問題。這就是為什麼很多人抱怨STL有嚴重的記憶體碎片的問題，因為太多的小記憶體的分配釋放了。有很多人會以為用記憶體池可以解決這個問題，但是實際上他們只是重新發明了Runtime-C或作業系統的記憶體管理機制，完全於事無補。當然解決記憶體碎片的問題還是通過記憶體池，具體來說是一系列不同尺寸的記憶體池（這個留給大家自己去思考）。當然，少進行動態記憶體分配是最好的。說到記憶體池就需要說一下池化技術。比如執行緒池，連接池等。池化技術對於一些短作業來說（如http服務） 相當相當的有效。這項技術可以減少連結建立，執行緒創建的開銷，從而提高性能。

·         非同步作業。我們知道Unix下的檔操作是有block和non-block的方式的，像有些系統調用也是block式的，如：Socket下的select，Windows下的WaitforObject之類的，如果我們的程式是同步操作，那麼會非常影響性能，我們可以改成非同步的，但是改成非同步的方式會讓你的程式變複雜。非同步方式一般要通過佇列，要注間佇列的性能問題，另外，非同步下的狀態通知通常是個問題，比如消息事件通知方式，有callback方式，等，這些方式同樣可能會影響你的性能。但是通常來說，非同步作業會讓性能的吞吐率有很大提升（Throughput），但是會犧牲系統的回應時間（latency）。這需要業務上支援。

·         語言和代碼庫。我們要熟悉語言以及所使用的函式程式庫或類庫的性能。比如：STL中的很多容器分配了記憶體後，那怕你刪除元素，記憶體也不會回收，其會造成記憶體洩露的假像，並可能造成記憶體碎片問題。再如，STL某些容器的size()==0  和 empty()是不一樣的，因為，size()是O(n)複雜度，empty()是O(1)的複雜度，這個要小心。Java中的JVM調優需要使用的這些參數：-Xms -Xmx -Xmn -XX:SurvivorRatio -XX:MaxTenuringThreshold，還需要注意JVM的GC，GC的霸氣大家都知道，尤其是full GC（還整理記憶體碎片），他就像“恐龍特級克賽號”一樣，他運行的時候，整個世界的時間都停止了。

4.3）網路調優

關於網路調優，尤其是TCP Tuning（你可以以這兩個關鍵字在網上找到很多文章），這裡面有很多很多東西可以說。看看Linux下TCP/IP的那麼多參數就知道了（順便說一下，你也許不喜歡Linux，但是你不能否認Linux給我們了很多可以進行內核調優的權力）。強烈建議大家看看《TCP/IP 詳解 卷1:協議》這本書。我在這裡只講一些概念上的東西。

A） TCP調優

我們知道TCP連結是有很多開銷的，一個是會佔用檔描述符，另一個是會開緩存，一般來說一個系統可以支援的TCP連結數是有限的，我們需要清楚地認識到TCP連結對系統的開銷是很大的。正是因為TCP是耗資源的，所以，很多攻擊都是讓你系統上出現大量的TCP連結，把你的系統資源耗盡。比如著名的SYNC Flood攻擊。

所以，我們要注意配置KeepAlive參數，這個參數的意思是定義一個時間，如果連結上沒有資料傳輸，系統會在這個時間發一個包，如果沒有收到回應，那麼TCP就認為連結斷了，然後就會把連結關閉，這樣可以回收系統資源開銷。（注：HTTP層上也有KeepAlive參數）對於像HTTP這樣的短連結，設置一個1-2分鐘的keepalive非常重要。這可以在一定程度上防止DoS攻擊。有下面幾個參數（下面這些參數的值僅供參考）：

1 2 3

net.ipv4.tcp_keepalive_probes = 5 net.ipv4.tcp_keepalive_intvl = 20 net.ipv4.tcp_fin_timeout = 30

對於TCP的TIME_WAIT這個狀態，主動關閉的一方進入TIME_WAIT狀態，TIME_WAIT狀態將持續2個MSL(Max Segment Lifetime)，默認為4分鐘，TIME_WAIT狀態下的資源不能回收。有大量的TIME_WAIT連結的情況一般是在HTTP伺服器上。對此，有兩個參數需要注意，

1 2	net.ipv4.tcp_tw_reuse=1 net.ipv4.tcp_tw_recycle=1

前者表示重用TIME_WAIT，後者表示回收TIME_WAIT的資源。

TCP還有一個重要的概念叫RWIN（TCP Receive Window Size），這個東西的意思是，我一個TCP連結在沒有向Sender發出ack時可以接收到的最大的資料包。為什麼這個很重要？因為如果Sender沒有收到Receiver發過來ack，Sender就會停止發送資料並會等一段時間，如果超時，那麼就會重傳。這就是為什麼TCP連結是可靠連結的原因。重傳還不是最嚴重的，如果有丟包發生的話，TCP的頻寬使用率會馬上受到影響（會盲目減半），再丟包，再減半，然後如果不丟包了，就逐步恢復。相關參數如下：

1 2 3 4

net.core.wmem_default = 8388608 net.core.rmem_default = 8388608 net.core.rmem_max = 16777216 net.core.wmem_max = 16777216

一般來說，理論上的RWIN應該設置成：輸送量  * 回路時間。Sender端的buffer應該和RWIN有一樣的大小，因為Sender端發送完資料後要等Receiver端確認，如果網路延時很大，buffer過小了，確認的次數就會多，於是性能就不高，對網路的利用率也就不高了。也就是說，對於延遲大的網路，我們需要大的buffer，這樣可以少一點ack，多一些資料，對於回應快一點的網路，可以少一些buffer。因為，如果有丟包（沒有收到ack），buffer過大可能會有問題，因為這會讓TCP重傳所有的資料，反而影響網路性能。（當然，網路差的情況下，就別玩什麼高性能了） 所以，高性能的網路重要的是要讓網路丟包率非常非常地小（基本上是用在LAN裡），如果網路基本是可信的，這樣用大一點的buffer會有更好的網路傳輸性能（來來回回太多太影響性能了）。

另外，我們想一想，如果網路品質非常好，基本不丟包，而業務上我們不怕偶爾丟幾個包，如果是這樣的話，那麼，我們為什麼不用速度更快的UDP呢？你想過這個問題了嗎？

B）UDP調優

說到UDP的調優，有一些事我想重點說一樣，那就是MTU——最大傳輸單元（其實這對TCP也一樣，因為這是鏈路層上的東西）。所謂最大傳輸單元，你可以想像成是公路上的公車，假設一個公車可以最多坐70人，頻寬就像是公路的車道數一樣，如果一條路上最多可以容下100輛公車，那意味著我最多可以運送7000人，但是如果公車坐不滿，比如平均每輛車只有20人，那麼我只運送了2000人，於是我公路資源（頻寬資源）就被浪費了。 所以，我們對於一個UDP的包，我們要儘量地讓他大到MTU的最大尺寸再往網路上傳，這樣可以最大化頻寬利用率。對於這個MTU，乙太網是1500位元組，光纖是4352位元組，802.11無線網是7981。但是，當我們用TCP/UDP發包的時候，我們的有效負載Payload要低於這個值，因為IP協定會加上20個位元組，UDP會加上8個位元組（TCP加的更多），所以，一般來說，你的一個UDP包的最大應該是1500-8-20=1472，這是你的資料的大小。當然，如果你用光纖的話， 這個值就可以更大一些。（順便說一下，對於某些NB的千光以態網網卡來說，在網卡上，網卡硬體如果發現你的包的大小超過了MTU，其會幫你做fragment，到了目標端又會幫你做重組，這就不需要你在程式中處理了）

再多說一下，使用Socket程式設計的時候，你可以使用setsockopt() 設置 SO_SNDBUF/SO_RCVBUF 的大小，TTL和KeepAlive這些關鍵的設置，當然，還有很多，具體你可以查看一下Socket的手冊。

最後說一點，UDP還有一個最大的好處是multi-cast多播，這個技術對於你需要在內網裡通知多台結點時非常方便和高效。而且，多播這種技術對於機會的水準擴展（需要增加機器來偵聽多播資訊）也很有利。

C）網卡調優

對於網卡，我們也是可以調優的，這對於千兆以及網網卡非常必要，在Linux下，我們可以用ifconfig查看網上的統計資訊，如果我們看到overrun上有資料，我們就可能需要調整一下txqueuelen的尺寸（一般默認為1000），我們可以調大一些，如：ifconfig eth0 txqueuelen 5000。Linux下還有一個命令叫：ethtool可以用於設置網卡的緩衝區大小。在Windows下，我們可以在網卡適配器中的高級選項卡中調整相關的參數（如：Receive Buffers, Transmit Buffer等，不同的網卡有不同的參數）。把Buffer調大對於需要大資料量的網路傳輸非常有效。

D）其它網路性能

關於多工技術，也就是用一個執行緒來管理所有的TCP連結，有三個系統調用要重點注意：一個是select，這個系統調用只支援上限1024個連結，第二個是poll，其可以突破1024的限制，但是select和poll本質上是使用的輪詢機制，輪詢機制在連結多的時候性能很差，因主是O(n)的演算法，所以，epoll出現了，epoll是作業系統內核支援的，僅當在連結活躍時，作業系統才會callback，這是由作業系統通知觸發的，但其只有Linux Kernel 2.6以後才支持（準確說是2.5.44中引入的），當然，如果所有的連結都是活躍的，過多的使用epoll_ctl可能會比輪詢的方式還影響性能，不過影響的不大。

另外，關於一些和DNS Lookup的系統調用要小心，比如：gethostbyaddr/gethostbyname，這個函數可能會相當的費時，因為其要到網路上去找功能變數名稱，因為DNS的遞迴查詢，會導致嚴重超時，而又不能通過設置什麼參數來設置time out，對此你可以通過配置hosts檔來加快速度，或是自己在記憶體中管理對應表，在程式啟動時查好，而不要在運行時每次都查。另外，在多執行緒下面，gethostbyname會一個更嚴重的問題，就是如果有一個執行緒的gethostbyname發生阻塞，其它執行緒都會在gethostbyname處發生阻塞，這個比較變態，要小心。（你可以試試GNU的gethostbyname_r()，這個的性能要好一些） 這種到網上找資訊的東西很多，比如，如果你的Linux使用了NIS，或是NFS，某些使用者或檔相關的系統調用就很慢，所以要小心。

4.4）系統調優

A）I/O模型

前面說到過select/poll/epoll這三個系統調用，我們都知道，Unix/Linux下把所有的設備都當成檔來進行I/O，所以，那三個操作更應該算是I/O相關的系統調用。說到  I/O模型，這對於我們的I/O性能相當重要，我們知道，Unix/Linux經典的I/O方式是（關於Linux下的I/O模型，大家可以讀一下這篇文章《使用非同步I/O大大提高性能》）：

第一種，同步阻塞式I/O，這個不說了。

第二種，同步無阻塞方式。其通過fctnl設置 O_NONBLOCK 來完成。

第三種，對於select/poll/epoll這三個是I/O不阻塞，但是在事件上阻塞，算是：I/O非同步，事件同步的調用。

第四種，AIO方式。這種I/O 模型是一種處理與 I/O 並行的模型。I/O請求會立即返回，說明請求已經成功發起了。在後臺完成I/O操作時，向應用程式發起通知，通知有兩種方式：一種是產生一個信號，另一種是執行一個基於執行緒的回呼函數來完成這次 I/O 處理過程。

第四種因為沒有任何的阻塞，無論是I/O上，還是事件通知上，所以，其可以讓你充分地利用CPU，比起第二種同步無阻塞好處就是，第二種要你一遍一遍地去輪詢。Nginx之所所以高效，是其使用了epoll和AIO的方式來進行I/O的。

再說一下Windows下的I/O模型，

a）一個是WriteFile系統調用，這個系統調用可以是同步阻塞的，也可以是同步無阻塞的，關於看檔是不是以Overlapped打開的。關於同步無阻塞，需要設置其最後一個參數Overlapped，微軟叫Overlapped I/O，你需要WaitForSingleObject才能知道有沒有寫完成。這個系統調用的性能可想而知。

b）另一個叫WriteFileEx的系統調用，其可以實現非同步I/O，並可以讓你傳入一個callback函數，等I/O結束後回檔之， 但是這個回檔的過程Windows是把callback函數放到了APC（Asynchronous Procedure Calls）的佇列中，然後，只用當應用程式當前執行緒成為可被通知狀態（Alterable）時，才會被回檔。只有當你的執行緒使用了這幾個函數時WaitForSingleObjectEx, WaitForMultipleObjectsEx, MsgWaitForMultipleObjectsEx, SignalObjectAndWait 和 SleepEx，執行緒才會成為Alterable狀態。可見，這個模型，還是有wait，所以性能也不高。

c）然後是IOCP – IO Completion Port，IOCP會把I/O的結果放在一個佇列中，但是，偵聽這個佇列的不是主執行緒，而是專門來幹這個事的一個或多個執行緒去幹（老的平臺要你自己創建執行緒，新的平臺是你可以創建一個執行緒池）。IOCP是一個執行緒池模型。這個和Linux下的AIO模型比較相似，但是實現方式和使用方式完全不一樣。

當然，真正提高I/O性能方式是把和外設的I/O的次數降到最低，最好沒有，所以，對於讀來說，記憶體cache通常可以從質上提升性能，因為記憶體比外設快太多了。對於寫來說，cache住要寫的資料，少寫幾次，但是cache帶來的問題就是即時性的問題，也就是latency會變大，我們需要在寫的次數上和相應上做權衡。

B）多核CPU調優

關於CPU的多核技術，我們知道，CPU0是很關鍵的，如果0號CPU被用得過狠的話，別的CPU性能也會下降，因為CPU0是有調整功能的，所以，我們不能任由作業系統負載均衡，因為我們自己更瞭解自己的程式，所以，我們可以手動地為其分配CPU核，而不會過多地佔用CPU0，或是讓我們關鍵進程和一堆別的進程擠在一起。

·         對於Windows來說，我們可以通過“工作管理員”中的“進程”而中右鍵功能表中的“設置相關性……”（Set Affinity…）來設置並限制這個進程能被運行在哪些核上。

·         對於Linux來說，可以使用taskset命令來設置（你可以通過安裝schedutils來安裝這個命令：apt-get install schedutils）

多核CPU還有一個技術叫NUMA技術（Non-Uniform Memory Access）。傳統的多核運算是使用SMP(Symmetric Multi-Processor )模式，多個處理器共用一個集中的記憶體和I/O匯流排。於是就會出現一致記憶體訪問的問題，一致性通常意味著性能問題。NUMA模式下，處理器被劃分成多個node， 每個node有自己的本機存放區器空間。關於NUMA的一些技術細節，你可以查看一下這篇文章《Linux 的 NUMA 技術》，在Linux下，對NUMA調優的命令是：numactl 。如下麵的命令：（指定命令“myprogram arg1 arg2”運行在node 0 上，其記憶體分配在node 0 和 1上）

1	numactl --cpubind=0 --membind=0,1 myprogram arg1 arg2

當然，上面這個命令並不好，因為記憶體跨越了兩個node，這非常不好。最好的方式是只讓程式訪問和自己運行一樣的node，如：

1	$ numactl --membind 1 --cpunodebind 1 --localalloc myapplication

C）檔案系統調優

關於檔案系統，因為檔案系統也是有cache的，所以，為了讓檔案系統有最大的性能。首要的事情就是分配足夠大的記憶體，這個非常關鍵，在Linux下可以使用free命令來查看 free/used/buffers/cached，理想來說，buffers和cached應該有40%左右。然後是一個快速的硬碟控制器，SCSI會好很多。最快的是Intel SSD 固態硬碟，速度超快，但是寫次數有限。

接下來，我們就可以調優檔案系統配置了，對於Linux的Ext3/4來說，幾乎在所有情況下都有所説明的一個參數是關閉檔案系統存取時間，在/etc/fstab下看看你的檔案系統 有沒有noatime參數（一般來說應該有），還有一個是dealloc，它可以讓系統在最後時刻決定寫入檔發生時使用哪個塊，可優化這個寫入程式。還要注間一下三種日誌模式：data=journal、data=ordered和data=writeback。預設設置data=ordered提供性能和防護之間的最佳平衡。

當然，對於這些來說，ext4的默認設置基本上是最佳優化了。

這裡介紹一個Linux下的查看I/O的命令—— iotop，可以讓你看到各進程的磁片讀寫的負載情況。

其它還有一些關於NFS、XFS的調優，大家可以上google搜索一些相關優化的文章看看。關於各檔案系統，大家可以看一下這篇文章——《Linux日誌檔案系統及性能分析》

4.5）資料庫調優

資料庫調優並不是我的強項，我就僅用我非常有限的知識說上一些吧。注意，下面的這些東西並不一定正確，因為在不同的業務場景，不同的資料庫設計下可能會得到完全相反的結論，所以，我僅在這裡做一些一般性的說明，具體問題還要具體分析。

A）資料庫引擎調優

我對資料庫引擎不是熟，但是有幾個事情我覺得是一定要去瞭解的。

·         資料庫的鎖的方式。這個非常非常地重要。併發情況下，鎖是非常非常影響性能的。各種隔離級別，行鎖，表鎖，頁鎖，讀寫鎖，事務鎖，以及各種寫優先還是讀優先機制。性能最高的是不要鎖，所以，分庫分表，冗餘數據，減少一致性交易處理，可以有效地提高性能。NoSQL就是犧牲了一致性和交易處理，並冗餘數據，從而達到了分散式和高性能。

·         資料庫的存儲機制。不但要搞清楚各種類型欄位是怎麼存儲的，更重要的是資料庫的資料存儲方式，是怎麼分區的，是怎麼管理的，比如Oracle的資料檔案，表空間，段，等等。瞭解清楚這個機制可以減輕很多的I/O負載。比如：MySQL下使用show engines;可以看到各種存儲引擎的支援。不同的存儲引擎有不同的側重點，針對不同的業務或資料庫設計會讓你有不同的性能。

·         資料庫的分散式策略。最簡單的就是複製或鏡像，需要瞭解分散式的一致性演算法，或是主主同步，主從同步。通過瞭解這種技術的機理可以做到資料庫級別的水準擴展。

B）SQL語句優化

關於SQL語句的優化，首先也是要使用工具，比如：MySQL SQL Query Analyzer，Oracle SQL Performance Analyzer，或是微軟SQL Query Analyzer，基本上來說，所有的RMDB都會有這樣的工具，來讓你查看你的應用中的SQL的性能問題。 還可以使用explain來看看SQL語句最終Execution Plan會是什麼樣的。

還有一點很重要，資料庫的各種操作需要大量的記憶體，所以伺服器的記憶體要夠，優其應對那些多表查詢的SQL語句，那是相當的耗記憶體。

下面我根據我有限的資料庫SQL的知識說幾個會有性能問題的SQL：

·         全表檢索。比如：select * from user where lastname = “xxxx”，這樣的SQL語句基本上是全表查找，線性複雜度O(n)，記錄數越多，性能也越差（如：100條記錄的查找要50ms，一百萬條記錄需要5分鐘）。對於這種情況，我們可以有兩種方法提高性能：一種方法是分表，把記錄數降下來，另一種方法是建索引（為lastname建索引）。索引就像是key-value的資料結構一樣，key就是where後面的欄位，value就是物理行號，對索引的搜索複雜度是基本上是O(log(n)) ——用B-Tree實現索引（如：100條記錄的查找要50ms，一百萬條記錄需要100ms）。

·         索引。對於索引欄位，最好不要在欄位上做計算、類型轉換、函數、空值判斷、欄位連接操作，這些操作都會破壞索引原本的性能。當然，索引一般都出現在Where或是Order by字句中，所以對Where和Order by子句中的子段最好不要進行計算操作，或是加上什麼NOT之類的，或是使用什麼函數。

·         多表查詢。關係型數據庫最多的操作就是多表查詢，多表查詢主要有三個關鍵字，EXISTS，IN和JOIN（關於各種join，可以參看圖解SQL的Join一文）。基本來說，現代的資料引擎對SQL語句優化得都挺好的，JOIN和IN/EXISTS在結果上有些不同，但性能基本上都差不多。有人說，EXISTS的性能要好於IN，IN的性能要好於JOIN，我各人覺得，這個還要看你的資料、schema和SQL語句的複雜度，對於一般的簡單的情況來說，都差不多，所以千萬不要使用過多的嵌套，千萬不要讓你的SQL太複雜，寧可使用幾個簡單的SQL也不要使用一個巨大無比的嵌套N級的SQL。還有人說，如果兩個表的資料量差不多，Exists的性能可能會高於In，In可能會高於Join，如果這兩個表一大一小，那麼子查詢中，Exists用大表，In則用小表。這個，我沒有驗證過，放在這裡讓大家討論吧。另，有一篇關於SQL Server的文章大家可以看看《IN vs JOIN vs EXISTS》

·         JOIN操作。有人說，Join表的順序會影響性能，只要Join的結果集是一樣，性能和join的次序無關。因為後臺的資料庫引擎會幫我們優化的。Join有三種實現演算法，嵌套迴圈，排序歸併，和Hash式的Join。（MySQL只支持第一種）

o    嵌套迴圈，就好像是我們常見的多重嵌套迴圈。注意，前面的索引說過，資料庫的索引查找演算法用的是B-Tree，這是O(log(n))的演算法，所以，整個演算法複法度應該是O(log(n)) * O(log(m)) 這樣的。

o    Hash式的Join，主要解決嵌套迴圈的O(log(n))的複雜，使用一個臨時的hash表來標記。

o    排序歸併，意思是兩個表按照查詢欄位排好序，然後再合併。當然，索引欄位一般是排好序的。

還是那句話，具體要看什麼樣的資料，什麼樣的SQL語句，你才知道用哪種方法是最好的。

·         部分結果集。我們知道MySQL裡的Limit關鍵字，Oracle裡的rownum，SQL Server裡的Top都是在限制前幾條的返回結果。這給了我們資料庫引擎很多可以調優的空間。一般來說，返回top n的記錄資料需要我們使用order by，注意在這裡我們需要為order by的欄位建立索引。有了被建索引的order by後，會讓我們的select語句的性能不會被記錄數的所影響。使用這個技術，一般來說我們前臺會以分頁方式來顯現資料，Mysql用的是OFFSET，SQL Server用的是FETCH NEXT，這種Fetch的方式其實並不好是線性複雜度，所以，如果我們能夠知道order by欄位的第二頁的起始值，我們就可以在where語句裡直接使用>=的運算式來select，這種技術叫seek，而不是fetch，seek的性能比fetch要高很多。

·         字串。正如我前面所說的，字串操作對性能上有非常大的惡夢，所以，能用資料的情況就用數位，比如：時間，工號，等。

·         全文檢索。千萬不要用Like之類的東西來做全文檢索，如果要玩全文檢索，可以嘗試使用Sphinx。

·         其它。

o    不要select *，而是明確指出各個欄位，如果有多個表，一定要在欄位名前加上表名，不要讓引擎去算。

o    不要用Having，因為其要遍歷所有的記錄。性能差得不能再差。

o    盡可能地使用UNION ALL  取代  UNION。

o    索引過多，insert和delete就會越慢。而update如果update多數索引，也會慢，但是如果只update一個，則只會影響一個索引表。

o    等等。

關於SQL語句的優化，網上有很多文章， 不同的資料庫引擎有不同的優化技巧，正如本站以前轉發的《MySQL性能優化的最佳20+條經驗》

先寫這麼多吧，歡迎大家指正補充。

注：這篇文章的確是個大雜燴。其實其中的說到的很多技術在網上都有很多很多的技術文章，google一下就能找到一堆有很多細節的文章，所以我也就不寫了。這篇性能調優的文章寫作的動機是之前看到 @淘寶褚霸 強推的highscalability.com上的這篇文章：Big List Of 20 Common Bottlenecks，覺得這篇文章泛泛而談，覺得自己能寫得比它好，所以就產生了動機。

（轉載時請注明作者和出處，請勿用於商業用途）