性能優(yōu)化指南：性能優(yōu)化的一般性原則與方法

【本文轉自博客園 作者：xybaby 原文鏈接：https://www.cnblogs.com/xybaby/p/9055734.html】
作為一個程序員，性能優(yōu)化是常有的事情，不管是桌面應用還是web應用，不管是前端還是后端，不管是單點應用還是分布式系統(tǒng)。本文從以下幾個方面來思考這個問題：性能優(yōu)化的一般性原則，性能優(yōu)化的層次，性能優(yōu)化的通用方法。本文不限于任何語言、框架，不過可能會用Python語言來舉例。

　　不過囿于個人經(jīng)驗，可能更多的是從Linux服務端的角度來思考這些問題。

　　一般性原則

　　依據(jù)數(shù)據(jù)而不是憑空猜測

　　這是性能優(yōu)化的第一原則，當我們懷疑性能有問題的時候，應該通過測試、日志、profillig來分析出哪里有問題，有的放矢，而不是憑感覺、撞運氣。一個系統(tǒng)有了性能問題，瓶頸有可能是CPU，有可能是內存，有可能是IO(磁盤IO，網(wǎng)絡IO)，大方向的定位可以使用top以及stat系列來定位(vmstat，iostat，netstat...)，針對單個進程，可以使用pidstat來分析。

　　在本文中，主要討論的是CPU相關的性能問題。按照80/20定律，絕大多數(shù)的時間都耗費在少量的代碼片段里面，找出這些代碼唯一可靠的辦法就是profile，我所知的編程語言，都有相關的profile工具，熟練使用這些profile工具是性能優(yōu)化的第一步。

　　忌過早優(yōu)化

　　The real problem is that programmers have spent far too much time worrying about efficiency in the wrong places and at the wrong times; premature optimization is the root of all evil (or at least most of it) in programming.

　　我并不十分清楚Donald Knuth說出這句名言的上下文環(huán)境，但我自己是十分認同這個觀念的。在我的工作環(huán)境(以及典型的互聯(lián)網(wǎng)應用開發(fā))與編程模式下，追求的是快速的迭代與試錯，過早的優(yōu)化往往是無用功。而且，過早的優(yōu)化很容易拍腦袋，優(yōu)化的點往往不是真正的性能瓶頸。

　　忌過度優(yōu)化

　　As performance is part of the specification of a program – a program that is unusably slow is not fit for purpose

　　性能優(yōu)化的目標是追求合適的性價比。

　　在不同的階段，我們對系統(tǒng)的性能會有一定的要求，比如吞吐量要達到多少多少。如果達不到這個指標，就需要去優(yōu)化。如果能滿足預期，那么就無需花費時間精力去優(yōu)化，比如只有幾十個人使用的內部系統(tǒng)，就不用按照十萬在線的目標去優(yōu)化。

　　而且，后面也會提到，一些優(yōu)化方法是“有損”的，可能會對代碼的可讀性、可維護性有副作用。這個時候，就更不能過度優(yōu)化。

　　深入理解業(yè)務

　　代碼是服務于業(yè)務的，也許是服務于最終用戶，也許是服務于其他程序員。不了解業(yè)務，很難理解系統(tǒng)的流程，很難找出系統(tǒng)設計的不足之處。后面還會提及對業(yè)務理解的重要性。

　　性能優(yōu)化是持久戰(zhàn)

　　當核心業(yè)務方向明確之后，就應該開始關注性能問題，當項目上線之后，更應該持續(xù)的進行性能檢測與優(yōu)化。

　　現(xiàn)在的互聯(lián)網(wǎng)產(chǎn)品，不再是一錘子買賣，在上線之后還需要持續(xù)的開發(fā)，用戶的涌入也會帶來性能問題。因此需要自動化的檢測性能問題，保持穩(wěn)定的測試環(huán)境，持續(xù)的發(fā)現(xiàn)并解決性能問題，而不是被動地等到用戶的投訴。

　　選擇合適的衡量指標、測試用例、測試環(huán)境

　　正因為性能優(yōu)化是一個長期的行為，所以需要固定衡量指標、測試用例、測試環(huán)境，這樣才能客觀反映性能的實際情況，也能展現(xiàn)出優(yōu)化的效果。

　　衡量性能有很多指標，比如系統(tǒng)響應時間、系統(tǒng)吞吐量、系統(tǒng)并發(fā)量。不同的系統(tǒng)核心指標是不一樣的，首先要明確本系統(tǒng)的核心性能訴求，固定測試用例;其次也要兼顧其他指標，不能顧此失彼。

　　測試環(huán)境也很重要，有一次突然發(fā)現(xiàn)我們的QPS高了許多，但是程序壓根兒沒優(yōu)化，查了半天，才發(fā)現(xiàn)是換了一個更牛逼的物理機做測試服務器。

　　性能優(yōu)化的層次

　　按照我的理解可以分為需求階段，設計階段，實現(xiàn)階段;越上層的階段優(yōu)化效果越明顯，同時也更需要對業(yè)務、需求的深入理解。

　　需求階段

　　不戰(zhàn)而屈人之兵，善之善者也

　　程序員的需求可能來自PM、UI的業(yè)務需求(或者說是功能性需求)，也可能來自Team Leader的需求。當我們拿到一個需求的時候，首先需要的是思考、討論需求的合理性，而不是立刻去設計、去編碼。

　　需求是為了解決某個問題，問題是本質，需求是解決問題的手段。那么需求是否能否真正的解決問題，程序員也得自己去思考，在之前的文章也提到過，產(chǎn)品經(jīng)理(特別是知道一點技術的產(chǎn)品經(jīng)理)的某個需求可能只是某個問題的解決方案，他認為這個方法可以解決他的問題，于是把解決方案當成了需求，而不是真正的問題。

　　需求討論的前提對業(yè)務的深入了解，如果不了解業(yè)務，根本沒法討論。即使需求已經(jīng)實現(xiàn)了，當我們發(fā)現(xiàn)有性能問題的時候，首先也可以從需求出發(fā)。

　　需求分析對性能優(yōu)化有什么幫助呢，第一，為了達到同樣的目的，解決同樣問題，也許可以有性能更優(yōu)(消耗更小)的辦法。這種優(yōu)化是無損的，即不改變需求本質的同時，又能達到性能優(yōu)化的效果;第二種情況，有損的優(yōu)化，即在不明顯影響用戶的體驗，稍微修改需求、放寬條件，就能大大解決性能問題。PM退步一小步，程序前進一大步。

　　需求討論也有助于設計時更具擴展性，應對未來的需求變化，這里按下不表。

　　設計階段

　　高手都是花80%時間思考，20%時間實現(xiàn);新手寫起代碼來很快，但后面是無窮無盡的修bug

　　設計的概念很寬泛，包括架構設計、技術選型、接口設計等等。架構設計約束了系統(tǒng)的擴展、技術選型決定了代碼實現(xiàn)。編程語言、框架都是工具，不同的系統(tǒng)、業(yè)務需要選擇適當?shù)墓ぞ呒Ｈ绻O計的時候做的不夠好，那么后面就很難優(yōu)化，甚至需要推到重來。

　　實現(xiàn)階段

　　實現(xiàn)是把功能翻譯成代碼的過程，這個層面的優(yōu)化，主要是針對一個調用流程，一個函數(shù)，一段代碼的優(yōu)化。各種profile工具也主要是在這個階段生效。除了靜態(tài)的代碼的優(yōu)化，還有編譯時優(yōu)化，運行時優(yōu)化。后二者要求就很高了，程序員可控性較弱。

　　代碼層面，造成性能瓶頸的原因通常是高頻調用的函數(shù)、或者單次消耗非常高的函數(shù)、或者二者的結合。

　　下面介紹針對設計階段與實現(xiàn)階段的優(yōu)化手段。

　　一般性方法

　　緩存

　　沒有什么性能問題是緩存解決不了的，如果有，那就再加一級緩存

　　a cache /k??/ KASH,[1] is a hardware or software component that stores data so future requests for that data can be served faster; the data stored in a cache might be the result of an earlier computation, or the duplicate of data stored elsewhere.

　　緩存的本質是加速訪問，訪問的數(shù)據(jù)要么是其他數(shù)據(jù)的副本 -- 讓數(shù)據(jù)離用戶更近;要么是之前的計算結果 -- 避免重復計算.

　　緩存需要用空間換時間，在緩存空間有限的情況下，需要優(yōu)秀的置換換算來保證緩存有較高的命中率。

　　數(shù)據(jù)的緩存

　　這是我們最常見的緩存形式，將數(shù)據(jù)緩存在離使用者更近的地方。比如操作系統(tǒng)中的CPU cache、disk cache。對于一個web應用，前端會有瀏覽器緩存，有CDN，有反向代理提供的靜態(tài)內容緩存;后端則有本地緩存、分布式緩存。

　　數(shù)據(jù)的緩存，很多時候是設計層面的考慮。

　　對于數(shù)據(jù)緩存，需要考慮的是緩存一致性問題。對于分布式系統(tǒng)中有強一致性要求的場景，可行的解決辦法有l(wèi)ease，版本號。

　　計算結果的緩存

　　對于消耗較大的計算，可以將計算結果緩存起來，下次直接使用。

　　我們知道，對遞歸代碼的一個有效優(yōu)化手段就是緩存中間結果，lookup table，避免了重復計算。python中的method cache就是這種思想.

　　對于可能重復創(chuàng)建、銷毀，且創(chuàng)建銷毀代價很大的對象，比如進程、線程，也可以緩存，對應的緩存形式如單例、資源池(連接池、線程池)。

　　對于計算結果的緩存，也需要考慮緩存失效的情況，對于pure function，固定的輸入有固定的輸出，緩存是不會失效的。但如果計算受到中間狀態(tài)、環(huán)境變量的影響，那么緩存的結果就可能失效，比如我在前面提到的python method cache

　　并發(fā)

　　一個人干不完的活，那就找兩個人干。并發(fā)既增加了系統(tǒng)的吞吐，又減少了用戶的平均等待時間。

　　這里的并發(fā)是指廣義的并發(fā)，粒度包括多機器(集群)、多進程、多線程。

　　對于無狀態(tài)(狀態(tài)是指需要維護的上下文環(huán)境，用戶請求依賴于這些上下文環(huán)境)的服務，采用集群就能很好的伸縮，增加系統(tǒng)的吞吐，比如掛載nginx之后的web server

　　對于有狀態(tài)的服務，也有兩種形式，每個節(jié)點提供同樣的數(shù)據(jù)，如mysql的讀寫分離;每個節(jié)點只提供部分數(shù)據(jù)，如mongodb中的sharding

　　分布式存儲系統(tǒng)中，partition(sharding)和replication(backup)都有助于并發(fā)。

　　絕大多數(shù)web server，要么使用多進程，要么使用多線程來處理用戶的請求，以充分利用多核CPU，再有IO阻塞的地方，也是適合使用多線程的。比較新的協(xié)程(Python greenle、goroutine)也是一種并發(fā)。

　　惰性

　　將計算推遲到必需的時刻，這樣很可能避免了多余的計算，甚至根本不用計算，這個在之前的《lazy ideas in programming》一文中舉了許多例子。

　　CopyOnWrite這個思想真牛逼

　　批量，合并

　　在有IO(網(wǎng)絡IO，磁盤IO)的時候，合并操作、批量操作往往能提升吞吐，提高性能。

　　我們最常見的是批量讀：每次讀取數(shù)據(jù)的時候多讀取一些，以備不時之需。如GFS client會從GFS master多讀取一些chunk信息;如分布式系統(tǒng)中，如果集中式節(jié)點復雜全局ID生成，俺么應用就可以一次請求一批id。

　　特別是系統(tǒng)中有單點存在的時候，緩存和批量本質上來說減少了與單點的交互，是減輕單點壓力的經(jīng)濟有效的方法

　　在前端開發(fā)中，經(jīng)常會有資源的壓縮和合并，也是這種思想。

　　當涉及到網(wǎng)絡請求的時候，網(wǎng)絡傳輸?shù)臅r間可能遠大于請求的處理時間，因此合并網(wǎng)絡請求就很有必要，比如mognodb的bulk operation，redis 的pipeline。寫文件的時候也可以批量寫，以減少IO開銷，GFS中就是這么干的

　　更高效的實現(xiàn)

　　同一個算法，肯定會有不同的實現(xiàn)，那么就會有不同的性能;有的實現(xiàn)可能是時間換空間，有的實現(xiàn)可能是空間換時間，那么就需要根據(jù)自己的實際情況權衡。

　　程序員都喜歡早輪子，用于練手無可厚非，但在項目中，使用成熟的、經(jīng)過驗證的輪子往往比自己造的輪子性能更好。當然不管使用別人的輪子，還是自己的工具，當出現(xiàn)性能的問題的時候，要么優(yōu)化它，要么替換掉他。

　　比如，我們有一個場景，有大量復雜的嵌套對象的序列化、反序列化，開始的時候是使用python(Cpython)自帶的json模塊，即使發(fā)現(xiàn)有性能問題也沒法優(yōu)化，網(wǎng)上一查，替換成了ujson，性能好了不少。

　　上面這個例子是無損的，但一些更高效的實現(xiàn)也可能是有損的，比如對于python，如果發(fā)現(xiàn)性能有問題，那么很可能會考慮C擴展，但也會帶來維護性與靈活性的喪失，面臨crash的風險。

　　縮小解空間

　　縮小解空間的意思是說，在一個更小的數(shù)據(jù)范圍內進行計算，而不是遍歷全部數(shù)據(jù)。最常見的就是索引，通過索引，能夠很快定位數(shù)據(jù)，對數(shù)據(jù)庫的優(yōu)化絕大多數(shù)時候都是對索引的優(yōu)化。

　　如果有本地緩存，那么使用索引也會大大加快訪問速度。不過，索引比較適合讀多寫少的情況，畢竟索引的構建也是需有消耗的。

　　另外在游戲服務端，使用的分線和AOI(格子算法)也都是縮小解空間的方法。

　　性能優(yōu)化與代碼質量

　　很多時候，好的代碼也是高效的代碼，各種語言都會有一本類似的書《effective xx》。比如對于python，pythonic的代碼通常效率都不錯，如使用迭代器而不是列表(python2.7 dict的iteritems(), 而不是items())。

　　衡量代碼質量的標準是可讀性、可維護性、可擴展性，但性能優(yōu)化有可能會違背這些特性，比如為了屏蔽實現(xiàn)細節(jié)與使用方式，我們會可能會加入接口層(虛擬層)，這樣可讀性、可維護性、可擴展性會好很多，但是額外增加了一層函數(shù)調用，如果這個地方調用頻繁，那么也是一筆開銷;又如前面提到的C擴展，也是會降低可維護性、

　　這種有損代碼質量的優(yōu)化，應該放到最后，不得已而為之，同時寫清楚注釋與文檔。

　　為了追求可擴展性，我們經(jīng)常會引入一些設計模式，如狀態(tài)模式、策略模式、模板方法、裝飾器模式等，但這些模式不一定是性能友好的。所以，為了性能，我們可能寫出一些反模式的、定制化的、不那么優(yōu)雅的代碼，這些代碼其實是脆弱的，需求的一點點變動，對代碼邏輯可能有至關重要的影響，所以還是回到前面所說，不要過早優(yōu)化，不要過度優(yōu)化。

　　總結

　　來張腦圖總結一下

　　本文版權歸作者xybaby(博文地址：http://www.cnblogs.com/xybaby/)所有。