系統(tǒng)性能定義
讓我們先來說說如何什么是系統(tǒng)性能。這個定義非常關鍵，如果我們不清楚什么是系統(tǒng)性能，那么我們將無法定位之。我見過很多朋友會覺得這很容易，但是仔細一問，其實他們并沒有一個比較系統(tǒng)的方法，所以，在這里我想告訴大家如何系統(tǒng)地來定位性能。 總體來說，系統(tǒng)性能就是兩個事：
Throughput，吞吐量。也就是每秒鐘可以處理的請求數(shù)，任務數(shù)。
Latency， 系統(tǒng)延遲。也就是系統(tǒng)在處理一個請求或一個任務時的延遲。
一般來說，一個系統(tǒng)的性能受到這兩個條件的約束，缺一不可。比如，我的系統(tǒng)可以頂?shù)米∫话偃f的并發(fā)，但是系統(tǒng)的延遲是 2 分鐘以上，那么，這個一百萬的負載毫無意義。系統(tǒng)延遲很短，但是吞吐量很低，同樣沒有意義。所以，一個好的系統(tǒng)的性能測試必然受到這兩個條件的同時作用。 有經(jīng)驗的朋友一定知道，這兩個東西的一些關系：
Throughput 越大，Latency 會越差。因為請求量過大，系統(tǒng)太繁忙，所以響應速度自然會低。
Latency 越好，能支持的 Throughput 就會越高。因為 Latency 短說明處理速度快，于是就可以處理更多的請求。
系統(tǒng)性能測試
經(jīng)過上述的說明，我們知道要測試系統(tǒng)的性能，需要我們收集系統(tǒng)的 Throughput 和 Latency 這兩個值。
首先，需要定義 Latency 這個值，比如說，對于網(wǎng)站系統(tǒng)響應時間必需是 5 秒以內(對于某些實時系統(tǒng)可能需要定義的更短，比如 5ms 以內，這個更根據(jù)不同的業(yè)務來定義)
其次，開發(fā)性能測試工具，一個工具用來制造高強度的 Throughput，另一個工具用來測量 Latency。對于第一個工具，你可以參考一下“十個免費的 Web 壓力測試工具”，關于如何測量 Latency，你可以在代碼中測量，但是這樣會影響程序的執(zhí)行，而且只能測試到程序內部的 Latency，真正的 Latency 是整個系統(tǒng)都算上，包括操作系統(tǒng)和網(wǎng)絡的延時，你可以使用 Wireshark 來抓網(wǎng)絡包來測量。這兩個工具具體怎么做，這個還請大家自己思考去了。
最后，開始性能測試。你需要不斷地提升測試的 Throughput，然后觀察系統(tǒng)的負載情況，如果系統(tǒng)頂?shù)米?，那就觀察 Latency 的值。這樣，你就可以找到系統(tǒng)的最大負載，并且你可以知道系統(tǒng)的響應延時是多少。
再多說一些，
關于 Latency，如果吞吐量很少，這個值估計會非常穩(wěn)定，當吞吐量越來越大時，系統(tǒng)的 Latency 會出現(xiàn)非常劇烈的抖動，所以，我們在測量 Latency 的時候，我們需要注意到 Latency 的分布，也就是說，有百分之幾的在我們允許的范圍，有百分之幾的超出了，有百分之幾的完全不可接受。也許，平均下來的 Latency 達標了，但是其中僅有 50% 的達到了我們可接受的范圍。那也沒有意義。
關于性能測試，我們還需要定義一個時間段。比如：在某個吞吐量上持續(xù) 15 分鐘。因為當負載到達的時候，系統(tǒng)會變得不穩(wěn)定，當過了一兩分鐘后，系統(tǒng)才會穩(wěn)定。另外，也有可能是，你的系統(tǒng)在這個負載下前幾分鐘還表現(xiàn)正常，然后就不穩(wěn)定了，甚至垮了。所以，需要這么一段時間。這個值，我們叫做峰值極限。
性能測試還需要做 Soak Test，也就是在某個吞吐量下，系統(tǒng)可以持續(xù)跑一周甚至更長。這個值，我們叫做系統(tǒng)的正常運行的負載極限。
性能測試有很多很復要的東西，比如：burst test 等。 這里不能一一詳述，這里只說了一些和性能調優(yōu)相關的東西?？傊阅軠y試是一細活和累活。
定位性能瓶頸
有了上面的鋪墊，我們就可以測試到到系統(tǒng)的性能了，再調優(yōu)之前，我們先來說說如何找到性能的瓶頸。我見過很多朋友會覺得這很容易，但是仔細一問，其實他們并沒有一個比較系統(tǒng)的方法。
查看操作系統(tǒng)負載
首先，當我們系統(tǒng)有問題的時候，我們不要急于去調查我們代碼，這個毫無意義。我們首要需要看的是操作系統(tǒng)的報告?？纯床僮飨到y(tǒng)的 CPU 利用率，看看內存使用率，看看操作系統(tǒng)的 IO，還有網(wǎng)絡的 IO，網(wǎng)絡鏈接數(shù)，等等。Windows 下的 perfmon 是一個很不錯的工具，Linux 下也有很多相關的命令和工具，比如：SystemTap，LatencyTOP，vmstat, sar, iostat, top, tcpdump 等等 。通過觀察這些數(shù)據(jù)，我們就可以知道我們的軟件的性能基本上出在哪里。比如：
1、先看 CPU 利用率，如果 CPU 利用率不高，但是系統(tǒng)的 Throughput 和 Latency 上不去了，這說明我們的程序并沒有忙于計算，而是忙于別的一些事，比如 IO。(另外，CPU 的利用率還要看內核態(tài)的和用戶態(tài)的，內核態(tài)的一上去了，整個系統(tǒng)的性能就下來了。而對于多核 CPU 來說，CPU 0 是相當關鍵的，如果 CPU 0 的負載高，那么會影響其它核的性能，因為 CPU 各核間是需要有調度的，這靠 CPU0 完成)
2、然后，我們可以看一下 IO 大不大，IO 和 CPU 一般是反著來的，CPU 利用率高則 IO 不大，IO 大則 CPU 就小。關于 IO，我們要看三個事，一個是磁盤文件 IO，一個是驅動程序的 IO(如：網(wǎng)卡)，一個是內存換頁率。這三個事都會影響系統(tǒng)性能。
3、然后，查看一下網(wǎng)絡帶寬使用情況，在 Linux 下，你可以使用 iftop, iptraf, ntop, tcpdump 這些命令來查看?；蚴怯? Wireshark 來查看。
4、如果 CPU 不高，IO 不高，內存使用不高，網(wǎng)絡帶寬使用不高。但是系統(tǒng)的性能上不去。這說明你的程序有問題，比如，你的程序被阻塞了?？赡苁且驗榈饶莻€鎖，可能是因為等某個資源，或者是在切換上下文。
通過了解操作系統(tǒng)的性能，我們才知道性能的問題，比如：帶寬不夠，內存不夠，TCP 緩沖區(qū)不夠，等等，很多時候，不需要調整程序的，只需要調整一下硬件或操作系統(tǒng)的配置就可以了。
使用 Profiler 測試
接下來，我們需要使用性能檢測工具，也就是使用某個 Profiler 來差看一下我們程序的運行性能。如：Java 的 JProfiler/TPTP/CodePro Profiler，GNU 的 gprof，IBM 的 PurifyPlus，Intel 的 VTune，AMD 的 CodeAnalyst，還有 Linux 下的 OProfile/perf，后面兩個可以讓你對你的代碼優(yōu)化到 CPU 的微指令級別，如果你關心 CPU 的 L1/L2 的緩存調優(yōu)，那么你需要考慮一下使用 VTune。 使用這些 Profiler 工具，可以讓你程序中各個模塊函數(shù)甚至指令的很多東西，如：運行的時間 ，調用的次數(shù)，CPU 的利用率，等等。這些東西對我們來說非常有用。
我們重點觀察運行時間最多，調用次數(shù)最多的那些函數(shù)和指令。這里注意一下，對于調用次數(shù)多但是時間很短的函數(shù)，你可能只需要輕微優(yōu)化一下，你的性能就上去了(比如：某函數(shù)一秒種被調用 100 萬次，你想想如果你讓這個函數(shù)提高 0.01 毫秒的時間 ，這會給你帶來多大的性能)
使用 Profiler 有個問題我們需要注意一下，因為 Profiler 會讓你的程序運行的性能變低，像 PurifyPlus 這樣的工具會在你的代碼中插入很多代碼，會導致你的程序運行效率變低，從而沒發(fā)測試出在高吞吐量下的系統(tǒng)的性能，對此，一般有兩個方法來定位系統(tǒng)瓶頸：
1、在你的代碼中自己做統(tǒng)計，使用微秒級的計時器和函數(shù)調用計算器，每隔 10 秒把統(tǒng)計 log 到文件中。
2、分段注釋你的代碼塊，讓一些函數(shù)空轉，做 Hard Code 的 Mock，然后再測試一下系統(tǒng)的 Throughput 和 Latency 是否有質的變化，如果有，那么被注釋的函數(shù)就是性能瓶頸，再在這個函數(shù)體內注釋代碼，直到找到最耗性能的語句。
最后再說一點，對于性能測試，不同的 Throughput 會出現(xiàn)不同的測試結果，不同的測試數(shù)據(jù)也會有不同的測試結果。所以，用于性能測試的數(shù)據(jù)非常重要，性能測試中，我們需要觀測試不同 Throughput 的結果。
常見的系統(tǒng)瓶頸
下面這些東西是我所經(jīng)歷過的一些問題，也許并不全，也許并不對，大家可以補充指正，我純屬拋磚引玉。
一般來說，性能優(yōu)化也就是下面的幾個策略：
用空間換時間。各種 cache 如 CPU L1/L2/RAM 到硬盤，都是用空間來換時間的策略。這樣策略基本上是把計算的過程一步一步的保存或緩存下來，這樣就不用每次用的時候都要再計算一遍，比如數(shù)據(jù)緩沖，CDN，等。這樣的策略還表現(xiàn)為冗余數(shù)據(jù)，比如數(shù)據(jù)鏡象，負載均衡什么的。
用時間換空間。有時候，少量的空間可能性能會更好，比如網(wǎng)絡傳輸，如果有一些壓縮數(shù)據(jù)的算法(如前些天說的“Huffman 編碼壓縮算法” 和 “rsync 的核心算法”)，這樣的算法其實很耗時，但是因為瓶頸在網(wǎng)絡傳輸，所以用時間來換空間反而能省時間。
簡化代碼。最高效的程序就是不執(zhí)行任何代碼的程序，所以，代碼越少性能就越高。關于代碼級優(yōu)化的技術大學里的教科書有很多示例了。如：減少循環(huán)的層數(shù)，減少遞歸，在循環(huán)中少聲明變量，少做分配和釋放內存的操作，盡量把循環(huán)體內的表達式抽到循環(huán)外，條件表達的中的多個條件判斷的次序，盡量在程序啟動時把一些東西準備好，注意函數(shù)調用的開銷(棧上開銷)，注意面向對象語言中臨時對象的開銷，小心使用異常(不要用異常來檢查一些可接受可忽略并經(jīng)常發(fā)生的錯誤)，…… 等等，等等，這連東西需要我們非常了解編程語言和常用的庫。
并行處理。如果 CPU 只有一個核，你要玩多進程，多線程，對于計算密集型的軟件會反而更慢(因為操作系統(tǒng)調度和切換開銷很大)，CPU 的核多了才能真正體現(xiàn)出多進程多線程的優(yōu)勢。并行處理需要我們的程序有 Scalability，不能水平或垂直擴展的程序無法進行并行處理。從架構上來說，這表再為——是否可以做到不改代碼只是加加機器就可以完成性能提升?
總之，根據(jù) 2：8 原則來說，20% 的代碼耗了你 80% 的性能，找到那 20% 的代碼，你就可以優(yōu)化那 80% 的性能。下面的一些東西都是我的一些經(jīng)驗，我只例舉了一些最有價值的性能調優(yōu)的的方法，供你參考，也歡迎補充。
算法調優(yōu)
算法非常重要，好的算法會有更好的性能。舉幾個我經(jīng)歷過的項目的例子，大家可以感覺一下。
一個是 過濾算法，系統(tǒng)需要對收到的請求做過濾，我們把可以被 filter in/out 的東西配置在了一個文件中，原有的過濾算法是遍歷過濾配置，后來，我們找到了一種方法可以對這個過濾配置進行排序，這樣就可以用二分折半的方法來過濾，系統(tǒng)性能增加了 50%。
一個是 哈希算法。計算哈希算法的函數(shù)并不高效，一方面是計算太費時，另一方面是碰撞太高，碰撞高了就跟單向鏈表一個性能(可參看 Hash Collision DoS 問題)。我們知道，算法都是和需要處理的數(shù)據(jù)很有關系的，就算是被大家所嘲笑的“冒泡排序”在某些情況下(大多數(shù)數(shù)據(jù)是排好序的)其效率會高于所有的排序算法。哈希算法也一樣，廣為人知的哈希算法都是用英文字典做測試，但是我們的業(yè)務在數(shù)據(jù)有其特殊性，所以，對于還需要根據(jù)自己的數(shù)據(jù)來挑選適合的哈希算法。對于我以前的一個項目，公司內某牛人給我發(fā)來了一個哈希算法，結果讓我們的系統(tǒng)性能上升了 150%。(關于各種哈希算法，你一定要看看 StackExchange 上的這篇關于各種 hash 算法的文章 )
分而治之和預處理。以前有一個程序為了生成月報表，每次都需要計算很長的時間，有時候需要花將近一整天的時間。于是我們把我們找到了一種方法可以把這個算法發(fā)成增量式的，也就是說我每天都把當天的數(shù)據(jù)計算好了后和前一天的報表合并，這樣可以大大的節(jié)省計算時間，每天的數(shù)據(jù)計算量只需要 20 分鐘，但是如果我要算整個月的，系統(tǒng)則需要 10 個小時以上(SQL 語句在大數(shù)據(jù)量面前性能成級數(shù)性下降)。這種分而治之的思路在大數(shù)據(jù)面前對性能有很幫助，就像 merge 排序一樣。SQL 語句和數(shù)據(jù)庫的性能優(yōu)化也是這一策略，如：使用嵌套式的 Select 而不是笛卡爾積的 Select，使用視圖，等等。
代碼調優(yōu)
從我的經(jīng)驗上來說，代碼上的調優(yōu)有下面這幾點：
字符串操作。這是最費系統(tǒng)性能的事了，無論是 strcpy, strcat 還是 strlen，最需要注意的是字符串子串匹配。所以，能用整型最好用整型。舉幾個例子，第一個例子是 N 年前做銀行的時候，我的同事喜歡把日期存成字符串(如：2012-05-29 08:30:02)，我勒個去，一個 select where between 語句相當耗時。
另一個例子是，我以前有個同事把一些狀態(tài)碼用字符串來處理，他的理由是，這樣可以在界面上直接顯示，后來性能調優(yōu)的時候，我把這些狀態(tài)碼全改成整型，然后用位操作查狀態(tài)，因為有一個每秒鐘被調用了 150K 次的函數(shù)里面有三處需要檢查狀態(tài)，經(jīng)過改善以后，整個系統(tǒng)的性能上升了 30% 左右。還有一個例子是，我以前從事的某個產(chǎn)品編程規(guī)范中有一條是要在每個函數(shù)中把函數(shù)名定義出來，如：const char fname[]=”functionName()”, 這是為了好打日志，但是為什么不聲明成 static 類型的呢?
多線程調優(yōu)。有人說，thread is evil，這個對于系統(tǒng)性能在某些時候是個問題。因為多線程瓶頸就在于互斥和同步的鎖上，以及線程上下文切換的成本，怎么樣的少用鎖或不用鎖是根本(比如：多版本并發(fā)控制 (MVCC) 在分布式系統(tǒng)中的應用 中說的樂觀鎖可以解決性能問題)，此外，還有讀寫鎖也可以解決大多數(shù)是讀操作的并發(fā)的性能問題。
這里多說一點在 C++ 中，我們可能會使用線程安全的智能指針 AutoPtr 或是別的一些容器，只要是線程安全的，其不管三七二十一都要上鎖，上鎖是個成本很高的操作，使用 AutoPtr 會讓我們的系統(tǒng)性能下降得很快，如果你可以保證不會有線程并發(fā)問題，那么你應該不要用 AutoPtr。我記得我上次我們同事去掉智能指針的引用計數(shù)，讓系統(tǒng)性能提升了 50% 以上。對于 Java 對象的引用計數(shù)，如果我猜的沒錯的話，到處都是鎖，所以，Java 的性能問題一直是個問題。另外，線程不是越多越好，線程間的調度和上下文切換也是很夸張的事，盡可能的在一個線程里干，盡可能的不要同步線程。這會讓你有很多的性能。
內存分配。不要小看程序的內存分配。malloc/realloc/calloc 這樣的系統(tǒng)調非常耗時，尤其是當內存出現(xiàn)碎片的時候。我以前的公司出過這樣一個問題——在用戶的站點上，我們的程序有一天不響應了，用 GDB 跟進去一看，系統(tǒng) hang 在了 malloc 操作上，20 秒都沒有返回，重啟一些系統(tǒng)就好了。這就是內存碎片的問題。這就是為什么很多人抱怨 STL 有嚴重的內存碎片的問題，因為太多的小內存的分配釋放了。有很多人會以為用內存池可以解決這個問題，但是實際上他們只是重新發(fā)明了 Runtime-C 或操作系統(tǒng)的內存管理機制，完全于事無補。
當然解決內存碎片的問題還是通過內存池，具體來說是一系列不同尺寸的內存池(這個留給大家自己去思考)。當然，少進行動態(tài)內存分配是最好的。說到內存池就需要說一下池化技術。比如線程池，連接池等。池化技術對于一些短作業(yè)來說(如 http 服務) 相當相當?shù)挠行?。這項技術可以減少鏈接建立，線程創(chuàng)建的開銷，從而提高性能。
異步操作。我們知道 Unix 下的文件操作是有 block 和 non-block 的方式的，像有些系統(tǒng)調用也是 block 式的，如：Socket 下的 select，Windows 下的 WaitforObject 之類的，如果我們的程序是同步操作，那么會非常影響性能，我們可以改成異步的，但是改成異步的方式會讓你的程序變復雜。異步方式一般要通過隊列，要注間隊列的性能問題，另外，異步下的狀態(tài)通知通常是個問題，比如消息事件通知方式，有 callback 方式，等，這些方式同樣可能會影響你的性能。但是通常來說，異步操作會讓性能的吞吐率有很大提升(Throughput)，但是會犧牲系統(tǒng)的響應時間(latency)。這需要業(yè)務上支持。
語言和代碼庫。我們要熟悉語言以及所使用的函數(shù)庫或類庫的性能。比如：STL 中的很多容器分配了內存后，那怕你刪除元素，內存也不會回收，其會造成內存泄露的假像，并可能造成內存碎片問題。再如，STL 某些容器的 size()==0 和 empty() 是不一樣的，因為，size() 是 O(n) 復雜度，empty() 是 O(1) 的復雜度，這個要小心。Java 中的 JVM 調優(yōu)需要使用的這些參數(shù)：-Xms -Xmx -Xmn -XX:SurvivorRatio -XX:MaxTenuringThreshold，還需要注意 JVM 的 GC，GC 的霸氣大家都知道，尤其是 full GC(還整理內存碎片)，他就像“恐龍?zhí)丶壙速愄?rdquo;一樣，他運行的時候，整個世界的時間都停止了。
網(wǎng)絡調優(yōu)
關于網(wǎng)絡調優(yōu)，尤其是 TCP Tuning(你可以以這兩個關鍵詞在網(wǎng)上找到很多文章)，這里面有很多很多東西可以說?？纯?Linux 下 TCP/IP 的那么多參數(shù)就知道了(順便說一下，你也許不喜歡 Linux，但是你不能否認 Linux 給我們了很多可以進行內核調優(yōu)的權力)。強烈建議大家看看《TCP/IP 詳解 卷 1: 協(xié)議》這本書。我在這里只講一些概念上的東西。
TCP 調優(yōu)
我們知道 TCP 鏈接是有很多開銷的，一個是會占用文件描述符，另一個是會開緩存，一般來說一個系統(tǒng)可以支持的 TCP 鏈接數(shù)是有限的，我們需要清楚地認識到 TCP 鏈接對系統(tǒng)的開銷是很大的。正是因為 TCP 是耗資源的，所以，很多攻擊都是讓你系統(tǒng)上出現(xiàn)大量的 TCP 鏈接，把你的系統(tǒng)資源耗盡。比如著名的 SYNC Flood 攻擊。
所以，我們要注意配置 KeepAlive 參數(shù)，這個參數(shù)的意思是定義一個時間，如果鏈接上沒有數(shù)據(jù)傳輸，系統(tǒng)會在這個時間發(fā)一個包，如果沒有收到回應，那么 TCP 就認為鏈接斷了，然后就會把鏈接關閉，這樣可以回收系統(tǒng)資源開銷。(注：HTTP 層上也有 KeepAlive 參數(shù))對于像 HTTP 這樣的短鏈接，設置一個 1-2 分鐘的 keepalive 非常重要。這可以在一定程度上防止 DoS 攻擊。有下面幾個參數(shù)(下面這些參數(shù)的值僅供參考)：
net.ipv4.tcp_keepalive_probes = 5
net.ipv4.tcp_keepalive_intvl = 20
net.ipv4.tcp_fin_timeout = 30
對于 TCP 的 TIME_WAIT 這個狀態(tài)，主動關閉的一方進入 TIME_WAIT 狀態(tài)，TIME_WAIT 狀態(tài)將持續(xù) 2 個 MSL(Max Segment Lifetime)，默認為 4 分鐘，TIME_WAIT 狀態(tài)下的資源不能回收。有大量的 TIME_WAIT 鏈接的情況一般是在 HTTP 服務器上。對此，有兩個參數(shù)需要注意，
net.ipv4.tcp_tw_reuse=1
net.ipv4.tcp_tw_recycle=1
前者表示重用 TIME_WAIT，后者表示回收 TIME_WAIT 的資源。
TCP 還有一個重要的概念叫 RWIN(TCP Receive Window Size)，這個東西的意思是，我一個 TCP 鏈接在沒有向 Sender 發(fā)出 ack 時可以接收到的最大的數(shù)據(jù)包。為什么這個很重要?因為如果 Sender 沒有收到 Receiver 發(fā)過來 ack，Sender 就會停止發(fā)送數(shù)據(jù)并會等一段時間，如果超時，那么就會重傳。這就是為什么 TCP 鏈接是可靠鏈接的原因。重傳還不是最嚴重的，如果有丟包發(fā)生的話，TCP 的帶寬使用率會馬上受到影響(會盲目減半)，再丟包，再減半，然后如果不丟包了，就逐步恢復。相關參數(shù)如下：
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 端發(fā)送完數(shù)據(jù)后要等 Receiver 端確認，如果網(wǎng)絡延時很大，buffer 過小了，確認的次數(shù)就會多，于是性能就不高，對網(wǎng)絡的利用率也就不高了。也就是說，對于延遲大的網(wǎng)絡，我們需要大的 buffer，這樣可以少一點 ack，多一些數(shù)據(jù)，對于響應快一點的網(wǎng)絡，可以少一些 buffer。
因為，如果有丟包(沒有收到 ack)，buffer 過大可能會有問題，因為這會讓 TCP 重傳所有的數(shù)據(jù)，反而影響網(wǎng)絡性能。(當然，網(wǎng)絡差的情況下，就別玩什么高性能了) 所以，高性能的網(wǎng)絡重要的是要讓網(wǎng)絡丟包率非常非常地小(基本上是用在 LAN 里)，如果網(wǎng)絡基本是可信的，這樣用大一點的 buffer 會有更好的網(wǎng)絡傳輸性能(來來回回太多太影響性能了)。
另外，我們想一想，如果網(wǎng)絡質量非常好，基本不丟包，而業(yè)務上我們不怕偶爾丟幾個包，如果是這樣的話，那么，我們?yōu)槭裁床挥盟俣雀斓?UDP 呢?你想過這個問題了嗎?
UDP 調優(yōu)
說到 UDP 的調優(yōu)，有一些事我想重點說一樣，那就是 MTU——最大傳輸單元(其實這對 TCP 也一樣，因為這是鏈路層上的東西)。所謂最大傳輸單元，你可以想像成是公路上的公交車，假設一個公交車可以最多坐 70 人，帶寬就像是公路的車道數(shù)一樣，如果一條路上最多可以容下 100 輛公交車，那意味著我最多可以運送 7000 人，但是如果公交車坐不滿，比如平均每輛車只有 20 人，那么我只運送了 2000 人，于是我公路資源(帶寬資源)就被浪費了。 所以，我們對于一個 UDP 的包，我們要盡量地讓他大到 MTU 的最大尺寸再往網(wǎng)絡上傳，這樣可以最大化帶寬利用率。
對于這個 MTU，以太網(wǎng)是 1500 字節(jié)，光纖是 4352 字節(jié)，802.11 無線網(wǎng)是 7981。但是，當我們用 TCP/UDP 發(fā)包的時候，我們的有效負載 Payload 要低于這個值，因為 IP 協(xié)議會加上 20 個字節(jié)，UDP 會加上 8 個字節(jié)(TCP 加的更多)，所以，一般來說，你的一個 UDP 包的最大應該是 1500-8-20=1472，這是你的數(shù)據(jù)的大小。當然，如果你用光纖的話， 這個值就可以更大一些。(順便說一下，對于某些 NB 的千光以態(tài)網(wǎng)網(wǎng)卡來說，在網(wǎng)卡上，網(wǎng)卡硬件如果發(fā)現(xiàn)你的包的大小超過了 MTU，其會幫你做 fragment，到了目標端又會幫你做重組，這就不需要你在程序中處理了)
再多說一下，使用 Socket 編程的時候，你可以使用 setsockopt() 設置 SO_SNDBUF/SO_RCVBUF 的大小，TTL 和 KeepAlive 這些關鍵的設置，當然，還有很多，具體你可以查看一下 Socket 的手冊。
最后說一點，UDP 還有一個最大的好處是 multi-cast 多播，這個技術對于你需要在內網(wǎng)里通知多臺結點時非常方便和高效。而且，多播這種技術對于機會的水平擴展(需要增加機器來偵聽多播信息)也很有利。
網(wǎng)卡調優(yōu)
對于網(wǎng)卡，我們也是可以調優(yōu)的，這對于千兆以及網(wǎng)網(wǎng)卡非常必要，在 Linux 下，我們可以用 ifconfig 查看網(wǎng)上的統(tǒng)計信息，如果我們看到 overrun 上有數(shù)據(jù)，我們就可能需要調整一下 txqueuelen 的尺寸(一般默認為 1000)，我們可以調大一些，如：ifconfig eth0 txqueuelen 5000。Linux 下還有一個命令叫：ethtool 可以用于設置網(wǎng)卡的緩沖區(qū)大小。在 Windows 下，我們可以在網(wǎng)卡適配器中的高級選項卡中調整相關的參數(shù)(如：Receive Buffers, Transmit Buffer 等，不同的網(wǎng)卡有不同的參數(shù))。把 Buffer 調大對于需要大數(shù)據(jù)量的網(wǎng)絡傳輸非常有效。
其它網(wǎng)絡性能
關于多路復用技術，也就是用一個線程來管理所有的 TCP 鏈接，有三個系統(tǒng)調用要重點注意：一個是 select，這個系統(tǒng)調用只支持上限 1024 個鏈接，第二個是 poll，其可以突破 1024 的限制，但是 select 和 poll 本質上是使用的輪詢機制，輪詢機制在鏈接多的時候性能很差，因主是 O(n) 的算法，所以，epoll 出現(xiàn)了，epoll 是操作系統(tǒng)內核支持的，僅當在鏈接活躍時，操作系統(tǒng)才會 callback，這是由操作系統(tǒng)通知觸發(fā)的，但其只有 Linux Kernel 2.6 以后才支持(準確說是 2.5.44 中引入的)，當然，如果所有的鏈接都是活躍的，過多的使用 epoll_ctl 可能會比輪詢的方式還影響性能，不過影響的不大。
另外，關于一些和 DNS Lookup 的系統(tǒng)調用要小心，比如：gethostbyaddr/gethostbyname，這個函數(shù)可能會相當?shù)馁M時，因為其要到網(wǎng)絡上去找域名，因為 DNS 的遞歸查詢，會導致嚴重超時，而又不能通過設置什么參數(shù)來設置 time out，對此你可以通過配置 hosts 文件來加快速度，或是自己在內存中管理對應表，在程序啟動時查好，而不要在運行時每次都查。
另外，在多線程下面，gethostbyname 會一個更嚴重的問題，就是如果有一個線程的 gethostbyname 發(fā)生阻塞，其它線程都會在 gethostbyname 處發(fā)生阻塞，這個比較變態(tài)，要小心。(你可以試試 GNU 的 gethostbyname_r()，這個的性能要好一些) 這種到網(wǎng)上找信息的東西很多，比如，如果你的 Linux 使用了 NIS，或是 NFS，某些用戶或文件相關的系統(tǒng)調用就很慢，所以要小心。
系統(tǒng)調優(yōu)
I/O 模型
前面說到過 select/poll/epoll 這三個系統(tǒng)調用，我們都知道，Unix/Linux 下把所有的設備都當成文件來進行 I/O，所以，那三個操作更應該算是 I/O 相關的系統(tǒng)調用。說到 I/O 模型，這對于我們的 I/O 性能相當重要，我們知道，Unix/Linux 經(jīng)典的 I/O 方式是：
第一種，同步阻塞式 I/O，這個不說了。
第二種，同步無阻塞方式。其通過 fctnl 設置 O_NONBLOCK 來完成。
第三種，對于 select/poll/epoll 這三個是 I/O 不阻塞，但是在事件上阻塞，算是：I/O 異步，事件同步的調用。
第四種，AIO 方式。這種 I/O 模型是一種處理與 I/O 并行的模型。I/O 請求會立即返回，說明請求已經(jīng)成功發(fā)起了。在后臺完成 I/O 操作時，向應用程序發(fā)起通知，通知有兩種方式：一種是產(chǎn)生一個信號，另一種是執(zhí)行一個基于線程的回調函數(shù)來完成這次 I/O 處理過程。
第四種因為沒有任何的阻塞，無論是 I/O 上，還是事件通知上，所以，其可以讓你充分地利用 CPU，比起第二種同步無阻塞好處就是，第二種要你一遍一遍地去輪詢。Nginx 之所所以高效，是其使用了 epoll 和 AIO 的方式來進行 I/O 的。
再說一下 Windows 下的 I/O 模型，
a)一個是 WriteFile 系統(tǒng)調用，這個系統(tǒng)調用可以是同步阻塞的，也可以是同步無阻塞的，關于看文件是不是以 Overlapped 打開的。關于同步無阻塞，需要設置其最后一個參數(shù) Overlapped，微軟叫 Overlapped I/O，你需要 WaitForSingleObject 才能知道有沒有寫完成。這個系統(tǒng)調用的性能可想而知。
b)另一個叫 WriteFileEx 的系統(tǒng)調用，其可以實現(xiàn)異步 I/O，并可以讓你傳入一個 callback 函數(shù)，等 I/O 結束后回調之， 但是這個回調的過程 Windows 是把 callback 函數(shù)放到了 APC(Asynchronous Procedure Calls)的隊列中，然后，只用當應用程序當前線程成為可被通知狀態(tài)(Alterable)時，才會被回調。只有當你的線程使用了這幾個函數(shù)時 WaitForSingleObjectEx, WaitForMultipleObjectsEx, MsgWaitForMultipleObjectsEx, SignalObjectAndWait 和 SleepEx，線程才會成為 Alterable 狀態(tài)。可見，這個模型，還是有 wait，所以性能也不高。
c)然后是 IOCP – IO Completion Port，IOCP 會把 I/O 的結果放在一個隊列中，但是，偵聽這個隊列的不是主線程，而是專門來干這個事的一個或多個線程去干(老的平臺要你自己創(chuàng)建線程，新的平臺是你可以創(chuàng)建一個線程池)。IOCP 是一個線程池模型。這個和 Linux 下的 AIO 模型比較相似，但是實現(xiàn)方式和使用方式完全不一樣。
當然，真正提高 I/O 性能方式是把和外設的 I/O 的次數(shù)降到最低，最好沒有，所以，對于讀來說，內存 cache 通常可以從質上提升性能，因為內存比外設快太多了。對于寫來說，cache 住要寫的數(shù)據(jù)，少寫幾次，但是 cache 帶來的問題就是實時性的問題，也就是 latency 會變大，我們需要在寫的次數(shù)上和相應上做權衡。
多核 CPU 調優(yōu)
關于 CPU 的多核技術，我們知道，CPU0 是很關鍵的，如果 0 號 CPU 被用得過狠的話，別的 CPU 性能也會下降，因為 CPU0 是有調整功能的，所以，我們不能任由操作系統(tǒng)負載均衡，因為我們自己更了解自己的程序，所以，我們可以手動地為其分配 CPU 核，而不會過多地占用 CPU0，或是讓我們關鍵進程和一堆別的進程擠在一起。
對于 Windows 來說，我們可以通過“任務管理器”中的“進程”而中右鍵菜單中的“設置相關性……”(Set Affinity…)來設置并限制這個進程能被運行在哪些核上。
對于 Linux 來說，可以使用 taskset 命令來設置(你可以通過安裝 schedutils 來安裝這個命令：apt-get install schedutils)
多核 CPU 還有一個技術叫 NUMA 技術(Non-Uniform Memory Access)。傳統(tǒng)的多核運算是使用 SMP(Symmetric Multi-Processor ) 模式，多個處理器共享一個集中的存儲器和 I/O 總線。于是就會出現(xiàn)一致存儲器訪問的問題，一致性通常意味著性能問題。NUMA 模式下，處理器被劃分成多個 node， 每個 node 有自己的本地存儲器空間。關于 NUMA 的一些技術細節(jié)，你可以查看一下這篇文章《Linux 的 NUMA 技術》，在 Linux 下，對 NUMA 調優(yōu)的命令是：numactl 。如下面的命令：(指定命令“myprogram arg1 arg2”運行在 node 0 上，其內存分配在 node 0 和 1 上)
numactl --cpubind=0 --membind=0,1 myprogram arg1 arg2
當然，上面這個命令并不好，因為內存跨越了兩個 node，這非常不好。最好的方式是只讓程序訪問和自己運行一樣的 node，如：
$ numactl --membind 1 --cpunodebind 1 --localalloc myapplication
文件系統(tǒng)調優(yōu)關于文件系統(tǒng)，因為文件系統(tǒng)也是有 cache 的，所以，為了讓文件系統(tǒng)有最大的性能。首要的事情就是分配足夠大的內存，這個非常關鍵，在 Linux 下可以使用 free 命令來查看 free/used/buffers/cached，理想來說，buffers 和 cached 應該有 40% 左右。然后是一個快速的硬盤控制器，SCSI 會好很多。最快的是 Intel SSD 固態(tài)硬盤，速度超快，但是寫次數(shù)有限。
接下來，我們就可以調優(yōu)文件系統(tǒng)配置了，對于 Linux 的 Ext3/4 來說，幾乎在所有情況下都有所幫助的一個參數(shù)是關閉文件系統(tǒng)訪問時間，在 /etc/fstab 下看看你的文件系統(tǒng) 有沒有 noatime 參數(shù)(一般來說應該有)，還有一個是 dealloc，它可以讓系統(tǒng)在最后時刻決定寫入文件發(fā)生時使用哪個塊，可優(yōu)化這個寫入程序。還要注間一下三種日志模式：data=journal、data=ordered 和 data=writeback。默認設置 data=ordered 提供性能和防護之間的最佳平衡。
當然，對于這些來說，ext4 的默認設置基本上是最佳優(yōu)化了。
這里介紹一個 Linux 下的查看 I/O 的命令—— iotop，可以讓你看到各進程的磁盤讀寫的負載情況。
其它還有一些關于 NFS、XFS 的調優(yōu)，大家可以上 google 搜索一些相關優(yōu)化的文章看看。
數(shù)據(jù)庫調優(yōu)數(shù)據(jù)庫調優(yōu)并不是我的強項，我就僅用我非常有限的知識說上一些吧。注意，下面的這些東西并不一定正確，因為在不同的業(yè)務場景，不同的數(shù)據(jù)庫設計下可能會得到完全相反的結論，所以，我僅在這里做一些一般性的說明，具體問題還要具體分析。
數(shù)據(jù)庫引擎調優(yōu)
我對數(shù)據(jù)庫引擎不是熟，但是有幾個事情我覺得是一定要去了解的。
數(shù)據(jù)庫的鎖的方式。這個非常非常地重要。并發(fā)情況下，鎖是非常非常影響性能的。各種隔離級別，行鎖，表鎖，頁鎖，讀寫鎖，事務鎖，以及各種寫優(yōu)先還是讀優(yōu)先機制。性能最高的是不要鎖，所以，分庫分表，冗余數(shù)據(jù)，減少一致性事務處理，可以有效地提高性能。NoSQL 就是犧牲了一致性和事務處理，并冗余數(shù)據(jù)，從而達到了分布式和高性能。
數(shù)據(jù)庫的存儲機制。不但要搞清楚各種類型字段是怎么存儲的，更重要的是數(shù)據(jù)庫的數(shù)據(jù)存儲方式，是怎么分區(qū)的，是怎么管理的，比如 Oracle 的數(shù)據(jù)文件，表空間，段，等等。了解清楚這個機制可以減輕很多的 I/O 負載。比如：MySQL 下使用 show engines; 可以看到各種存儲引擎的支持。不同的存儲引擎有不同的側重點，針對不同的業(yè)務或數(shù)據(jù)庫設計會讓你有不同的性能。
數(shù)據(jù)庫的分布式策略。最簡單的就是復制或鏡像，需要了解分布式的一致性算法，或是主主同步，主從同步。通過了解這種技術的機理可以做到數(shù)據(jù)庫級別的水平擴展。
SQL 語句優(yōu)化
關于 SQL 語句的優(yōu)化，首先也是要使用工具，比如：MySQL SQL Query Analyzer，Oracle SQL Performance Analyzer，或是微軟 SQL Query Analyzer，基本上來說，所有的 RMDB 都會有這樣的工具，來讓你查看你的應用中的 SQL 的性能問題。 還可以使用 explain 來看看 SQL 語句最終 Execution Plan 會是什么樣的。
還有一點很重要，數(shù)據(jù)庫的各種操作需要大量的內存，所以服務器的內存要夠，優(yōu)其應對那些多表查詢的 SQL 語句，那是相當?shù)暮膬却妗?/p>
下面我根據(jù)我有限的數(shù)據(jù)庫 SQL 的知識說幾個會有性能問題的 SQL：
全表檢索。比如：select * from user where lastname = “xxxx”，這樣的 SQL 語句基本上是全表查找，線性復雜度 O(n)，記錄數(shù)越多，性能也越差(如：100 條記錄的查找要 50ms，一百萬條記錄需要 5 分鐘)。對于這種情況，我們可以有兩種方法提高性能：一種方法是分表，把記錄數(shù)降下來，另一種方法是建索引(為 lastname 建索引)。索引就像是 key-value 的數(shù)據(jù)結構一樣，key 就是 where 后面的字段，value 就是物理行號，對索引的搜索復雜度是基本上是 O(log(n)) ——用 B-Tree 實現(xiàn)索引(如：100 條記錄的查找要 50ms，一百萬條記錄需要 100ms)。
索引。對于索引字段，最好不要在字段上做計算、類型轉換、函數(shù)、空值判斷、字段連接操作，這些操作都會破壞索引原本的性能。當然，索引一般都出現(xiàn)在 Where 或是 Order by 字句中，所以對 Where 和 Order by 子句中的子段最好不要進行計算操作，或是加上什么 NOT 之類的，或是使用什么函數(shù)。
多表查詢。關系型數(shù)據(jù)庫最多的操作就是多表查詢，多表查詢主要有三個關鍵字，EXISTS，IN 和 JOIN(關于各種 join，可以參看圖解 SQL 的 Join 一文)。基本來說，現(xiàn)代的數(shù)據(jù)引擎對 SQL 語句優(yōu)化得都挺好的，JOIN 和 IN/EXISTS 在結果上有些不同，但性能基本上都差不多。有人說，EXISTS 的性能要好于 IN，IN 的性能要好于 JOIN，我各人覺得，這個還要看你的數(shù)據(jù)、schema 和 SQL 語句的復雜度，對于一般的簡單的情況來說，都差不多，所以千萬不要使用過多的嵌套，千萬不要讓你的 SQL 太復雜，寧可使用幾個簡單的 SQL 也不要使用一個巨大無比的嵌套 N 級的 SQL。
還有人說，如果兩個表的數(shù)據(jù)量差不多，Exists 的性能可能會高于 In，In 可能會高于 Join，如果這兩個表一大一小，那么子查詢中，Exists 用大表，In 則用小表。這個，我沒有驗證過，放在這里讓大家討論吧。另，有一篇關于 SQL Server 的文章大家可以看看《IN vs JOIN vs EXISTS》
JOIN 操作。有人說，Join 表的順序會影響性能，只要 Join 的結果集是一樣，性能和 join 的次序無關。因為后臺的數(shù)據(jù)庫引擎會幫我們優(yōu)化的。Join 有三種實現(xiàn)算法，嵌套循環(huán)，排序歸并，和 Hash 式的 Join。(MySQL 只支持第一種)
嵌套循環(huán)，就好像是我們常見的多重嵌套循環(huán)。注意，前面的索引說過，數(shù)據(jù)庫的索引查找算法用的是 B-Tree，這是 O(log(n)) 的算法，所以，整個算法復法度應該是 O(log(n)) * O(log(m)) 這樣的。
Hash 式的 Join，主要解決嵌套循環(huán)的 O(log(n)) 的復雜，使用一個臨時的 hash 表來標記。
排序歸并，意思是兩個表按照查詢字段排好序，然后再合并。當然，索引字段一般是排好序的。
還是那句話，具體要看什么樣的數(shù)據(jù)，什么樣的 SQL 語句，你才知道用哪種方法是最好的。
部分結果集。我們知道 MySQL 里的 Limit 關鍵字，Oracle 里的 rownum，SQL Server 里的 Top 都是在限制前幾條的返回結果。這給了我們數(shù)據(jù)庫引擎很多可以調優(yōu)的空間。一般來說，返回 top n 的記錄數(shù)據(jù)需要我們使用 order by，注意在這里我們需要為 order by 的字段建立索引。有了被建索引的 order by 后，會讓我們的 select 語句的性能不會被記錄數(shù)的所影響。使用這個技術，一般來說我們前臺會以分頁方式來顯現(xiàn)數(shù)據(jù)，Mysql 用的是 OFFSET，SQL Server 用的是 FETCH NEXT，這種 Fetch 的方式其實并不好是線性復雜度，所以，如果我們能夠知道 order by 字段的第二頁的起始值，我們就可以在 where 語句里直接使用>= 的表達式來 select，這種技術叫 seek，而不是 fetch，seek 的性能比 fetch 要高很多。
字符串。正如我前面所說的，字符串操作對性能上有非常大的惡夢，所以，能用數(shù)據(jù)的情況就用數(shù)字，比如：時間，工號，等。
全文檢索。千萬不要用 Like 之類的東西來做全文檢索，如果要玩全文檢索，可以嘗試使用 Sphinx。
其它。
不要 select *，而是明確指出各個字段，如果有多個表，一定要在字段名前加上表名，不要讓引擎去算。
不要用 Having，因為其要遍歷所有的記錄。性能差得不能再差。
盡可能地使用 UNION ALL 取代 UNION。
索引過多，insert 和 delete 就會越慢。而 update 如果 update 多數(shù)索引，也會慢，但是如果只 update 一個，則只會影響一個索引表。
等等。
下載文檔
