談到軟體產品的效能調優，我認為可以從狹義和廣義兩個範圍來理解。從狹義的範疇來看，效能調優主要是指通過修改軟體程式邏輯、結構等技術手段提公升軟體產品的各項效能指標，如響應時間等等；而從廣義的層面來看，就不僅限於程式內部了，因為造成系統效能問題的瓶頸很可能**於方方面面，而這種情況往往是效能調優很普遍的情況，下面就從廣義的範圍細分成幾個角度來進行闡述。
一、軟體層面
a）首先要談到的肯定是我們自己提供的軟體產品，因為它的內部設計是我們最清楚的，使用者在應用時遇到效能問題首先要質疑的也是我們的產品，因此這個層面的調優肯定是我們軟體**者的重中之重！舉例來說：比較複雜的業務，通常會在程式中輸出一些關鍵操作的執行時間，然後再分析哪些操作比較耗時，之後再找原因。具體分析原因就比較多了，比如多次迴圈查詢資料庫，複雜耗時的sql語句，頻繁的遠端呼叫，複雜演算法，等等。
b）資料庫層面：設計資料庫時應考慮到在少訪問和簡化、優化訪問的前提下實現產品功能，多用儲存過程代替完整sql，盡量用連線池使使用者和服務的連線實現可復用，盡量不使用游標結構等，對基本表的設計進行優化如第三正規化、引入「中間表」的技術思路，控制使用者實際資料量的增長；對資料庫進行索引優化，避免整表掃瞄；對資料庫的事務處理進行調優（去除不必要的鎖、將事務切分成小的粒度、適當降低隔離級別、減少訪問熱點等）；sql語句調優（盡量優化那些無意義的、拙劣的、複雜的sql）等等。這方面主要就是本著乙個通過盡可能少的磁碟訪問而獲得所需要的資料這麼乙個基本原則。
c）中介軟體軟體：某些軟體產品為資料庫、中介軟體、客戶端的三層架構設計，此時為系統執行提供服務的中介軟體軟體也將成為制約效能的乙個瓶頸。因此在這個層面上也是有很大調優空間的，比如各種相關引數的設定優化，使用效能包、效能監控分析工具等，避免競爭執行緒資源，批處理，堆大小的設定，為溢位條件設定執行佇列，後備緩衝，減少非重要應用的資源占用，使用集群等。舉個簡單的例項，我曾經遇到乙個產品的效能問題，當查詢資料大到一定程度時，系統一直灰屏宕機狀態，結果只是通過把jvm記憶體引數設定從預設值的128調為256就輕鬆解決了，只是引數值的乙個小變動，反映到具體的使用者面前就是出的來和出不來資料的本質差別！
d）作業系統：無論是伺服器還是使用者終端，都脫離不了作業系統這個基礎的應用平台的支援，因此這個層面的效能調優工作也千萬不能遺漏。例如同廠商的不同版本（如windows各系列）、不同廠商（ms/hp/sun等）不同的作業系統（windows/linux/unix等），這些作業系統的效能表現本身就有所差異，如記憶體的分配、虛擬記憶體的處理、資料的讀寫交換、相容穩定抗壓性等等方面，利用相應的調優方法和工具，可以對此環節進行優化。
二、硬體層面
a）cpu：**處理器，決定資料處理速度的核心部件，與效能表現的相關度可想而知，硬體方面具體調優方法及工具本文中不再贅述，下同！
b）記憶體、快取：資料交換的臨時儲存空間，它的大小形象的說就像是火車站候車室的面積，與效能的關係可想而知。比如有些程式設計的操作對記憶體**設計有漏洞，導致頻繁操作時記憶體洩漏越來越多，系統就會越來越慢。
c）硬碟、i/o：資料儲存、呼叫的載體，如果儲存器像候車室，那這些就像是車箱的大小與節數等。
d）網路：如果還是用坐火車為例，網路的差別就像是普通、快速、動車、磁浮等各種等級的差別，如果乙個「系統」頻繁需要通過火運完成，那它的效能表現和網路的相關性就不言而喻了。比如某些軟體功能設計時沒有考慮網路流量方面的風險，導致每次操作時網路連線次數很多，頻繁呼叫或是資料報過大，這些都會導致在一定網路條件下產生效能問題。
e）顯示卡等特殊硬體：不同軟體產品應用的業務可能用到不同的專用硬體或外設，比如乙個很炫的遊戲對顯示卡的要求就會很高，當顯示成為短板時宕機、跳幀等異常；乙個收款臺的掃瞄、信用卡pos機如果質量或相容性、穩定性不佳時，也可能會造成效能表現的不理想，等待諸如此類問題。
三、業務層面
a）業務流程重組：專案甲方在購買軟體產品或系統服務前，一般會找相關專家、售前人員作一些相關的評估或「體檢」，找出現有運作模式下的一些存在優化空間的錯誤環節或繁冗流程、制度體系等。因此在這個階段是否對專案應用方作了足夠的優化，也對未來產品上線後的應用效能表現在巨集觀上起著決定作用。取例來說：如果乙個系統設計前沒有作過這方面的優化，最後應用時需要100人操作10個步驟才能完成，通過流程重組後，從業務上只需要40個人幹5個步驟就搞定了，那麼沒上軟體前我們就能從理論上把效能表現優化80%！
b）需求定位：與上一條闡述的類似，只是介入的階段和角色有所區別。需求人員有時是從專案乙方發起的，主動地、有策略性的去選擇一些有代表性的單位去調研軟體產品的概要或詳細需求，為後續的產品開發設計提供依據。在這一階段是否有效的考慮了未來產品的效能表現，對其提出相關的設計目標，也對後續的效能表現有一定的影響。
c）實施方案：一般當大型一些的專案合同簽訂完畢後，就會分期安排實施人員負現場牽頭並組織雙方成立實施小組團隊，共同制訂系統的上線、操作培訓、應用方案等，並執行方案直至系統正常上線執行，專案交付。因此，這個方案制定的是否精簡、高效，也直接關係了使用者應用系統的效能表現。
四、意識層面
當今社會萬事講求以人為本，如果從軟體應用系統涉及的各級人員角色的內心沒有把效能表現當回事，那麼一切調優最多也都是亡羊補牢而已。比如：
a）產品經理：專案乙方產品總負責人，產品目標、市場定位、基本框架的制定者。
b）一線人員：售前諮詢、實施顧問等。
c）需求設計：對產品具體功能設計提出明確要求的角色。
d）**實現：按需求定義進行產品的具體實現的角色。
e）測試人員：對產品質量進行檢測、對開發過程進行監管的角色。
f）終端使用者：系統最終的使用者、應用效果的影響者。
對於乙個軟體產品來講，只有以上這些環節的角色人等在各自的工作崗位上，真正的在意識層面上提高優化系統效能的地位，而不是把它作為功能優先實現之外的附屬品，才能把系統效能優化的工作最大程度的作在前面、作的全面、作得到位！
綜上所述，我們看到了各類導致效能瓶頸的可能原因（也可以說是效能調優的入手點），下面我們用乙個比較常用的魚骨圖分析法來展示一下，可能會更為清晰：
然後我們再把這些原因按一定的規則進行分門別類，一般採用如下的二維矩陣分析的方法，按可推行的難易度和收效的影響度高低來形成四個象限，把這些問題按具體情況分布在這四個象限中，看到這些問題中哪些是我們要優先解決的，哪些是可以暫時放一放的，調優時可以借鑑這個順序來進行。
當然在不同的企業這四個象限中的原因分布是會相互轉化的，比如在乙個預算有限的私企中可能額外的硬體投資對其來說就是應該放入暫時擱置的象限，而對於財大氣粗的單位中可能費用預算不是問題但是想改變他的辦事流程和組織架構將是非常困難的，這時解決的優先次序也就要相應調整了。
調優 Nginx效能調優
一.nginx優化配置 1.主配置檔案優化 注 部分配置詳解 worker processes 8 nginx程序數，建議按照cpu數目來指定，一般為它的倍數。worker cpu affinity 00000001 00000010 00000100 00001000 00010000 00100...
Spark效能調優 JVM調優
通過一張圖讓你明白以下四個問題 1.jvm gc機制，堆記憶體的組成 2.spark的調優為什麼會和jvm的調優會有關聯？因為scala也是基於jvm執行的語言 3.spark中oom產生的原因 4.如何在jvm這個層面上來對spark進行調優 補充 spark程式執行時 jvm堆記憶體分配比例 r...
七 Spark效能調優 Shuffle 調優
目錄 一 調節 map 端緩衝區大小 二 調節 reduce 端拉取資料緩衝區大小 三 調節 reduce 端拉取資料重試次數 四 調節 reduce 端拉取資料等待間隔 五 調節 sortshuffle 排序操作閾值 val conf new sparkconf set spark.shuffle...