系统性能调优的各个方面
概述
?性能優化的思路
首先是較為精準的定位問題，借助于相應的工具包，分析系統性能瓶頸在哪，在根據其性能指標，以及所處于層級決定選擇優化的方式方法。在選擇優化的方式方法時，大家可以參照以下章節調優方法，架構優化遞進，進行正確的，有針對性，有步驟的優化。可能會發現部分指導思想或許有相悖嫌疑，大可不必較真，系統優化的過程本身就是一個不斷分離+共享的組合拳，至于具體選擇哪種優化方式，根據具體需求來定，但大型應用發展的總體思路是不斷分離，在通過索引（非數據庫）進行關聯起來，
切記：優化一定要對系統進行細致的望聞問切，找到性能問題根源切入點，而不被表象迷糊，對癥下藥，發現病癥所在的醫生并不比操作手術刀的醫生水平差。本文有工具包一章節，對于需要做優化的人員，需要熟悉，他就是我們診斷所用的CT，例如我們發現內存高了，首先想到不是內存不夠用，而是為什么如此消耗內存，用工具看看內存消耗在什么地方，試想之，如在醫院，病人告訴醫生，他心臟不好，醫生就換心臟，那樣的話，每個人只要熟練掌握菜刀，都可以做醫生
?迭代優化
性能優化未必一次性就能滿足的，可能此處瓶頸消失了，系統一旦運轉快速后，在其他地方又發現新的性能瓶頸，所以性能優化是一個迭代的工作。直至滿足系統需要的性能指標。
?優化的成本
系統性能設計或優化是否可以一步升天，按照最好的分布式架構進行設計和優化呢，單個節點一直也運轉及其健康，理論上是可以達到共產國際的，但實際實施層面不可取，必須結合實際的非功能需求進行設計和優化，一則一步到極致的話，系統的成本太過慮龐大，光是性能設計和優化的成本就高于系統本身給客戶所提供的價值，也造成研發成本開銷過大。二則好像能夠架構這樣完美系統的人還沒誕生。所以一句話也同樣適合架構師：有理想而不理想化，廢話少扯：具體見法則
調優方法
數據庫優化
很多應用，優化DB往往是最直接，最方便，見效最顯著的，但并非所有的系統性能都處在瓶頸，或者DB瓶頸解決之后，可能應用層瓶頸，WEB層瓶頸，甚至架構瓶頸都會冒出來了,所以數據庫優化十分重要，但往往很多人理解系統優化就是數據庫優化，是不全面的。優化角色一般推薦具備較深數據知識的程序員，或者專業的DBA,而不只是會CRUD開發人員
?建立正確的主鍵，外鍵，以及索引
?分離原則：讀寫分離，業務數據分離
a)分庫
b)分區
c)分表
d)分列（將大字段，不常用的隔離到他表，按需查詢）
?選擇隔離級別：某些對數據一致性要求不高的，可以犧牲部分一致性，降低加鎖阻塞
?保證事務簡短以及減少不必要的鎖機制。
?查詢優化規則：
e)避免表內的相關子查詢；
f)避免排序或為盡可能少的行排序，
g)做大量數據排序時相關數據放在臨時表中
h).盡量在where后多傳查詢條件，以減少不必要返回的行
i).盡量select只需要的字段,以減少不必要返回的列
?分頁存儲過程：大列表的查詢也可以利用分頁存儲過程達到優化效果。
?利用數據庫緩存，視圖，臨時表等最大程度優化系統，并對存儲過程和函數進行必要的優化
?如有需要，可以冗余表中字段，避免聯合查詢
?如有需要，也可以將表內的大字段分離到單獨表中，使其單獨查詢
?必做多表關聯時，盡量過濾不符條件表中數據，減少笛卡爾積計算量
?復雜表表：如實時性要求不高，盡量后臺任務計算，避免動態查詢
應用層優化
應用層優化側重于應用層本身的邏輯優化，算法優化，代碼優化等，優化的角色可以是熟悉應用的程序員
?優化算法，選擇合適高效的算法，降低不必要的遞歸，循環、多層循環嵌套等計算
?避免申請過多的不必要的內存開銷
?降低內存泄露（using，Dispose，弱引用，Finalize）
?使用頻率較低的大文件，大對象，大數組等使用完畢后，及時釋放
?使用頻率較高的大文件，大對象，大數組盡量緩存
?考慮多線程技術
?選擇適當的通信方式：長連接，短連接,有以下方式Socket、Remoting、Web Services(Rest,Soap)、WCF、Named Pipes
?降低應用之間通信次數，例用戶認證服務，工作流服務，數據庫服務
?降低應用之間傳輸數據量，不必要傳輸的不傳，少傳
?緩存機制：緩存常用的，不易變化的，偶有變化，可以考慮緩存依賴機制
?支持異步計算，降低等待時間
?考慮延遲加載，或者提前加載兩種方式
?分離原則：分離業務模塊,如分離大I/O模塊、分離高耗內存模塊，分離高耗寬帶模塊
?考慮分布式應用，分布式存儲，如以上所有仍然搞不定的
Web優化
Web優化偏向于熟悉前端開發的技術人員
?減少http請求
?避免404錯誤
?在html頁面header加入緩存標簽
?Gzip壓縮網頁
?減少cookie體積
?使用外部的js和css
?消減js和css
?壓縮js
?使用css sprites技術，眾多圖片合成在一起，通過CSS切分，降低圖片傳輸的頻率和數據量
?可以使用靜態網頁的，避免使用動態網頁
架構優化遞進
為以示與應用層優化的區別，本文對架構的描述更側重偏向于物理層面，再次贅述下，涉及變更架構的，需要我們的應用具有良好的拓展性，考驗我們的架構師平時的功底，如何剛剛好滿足需求以及兩三年內業務增量，但并非架構做的越強大，越靈活，越可配置，越易水平拓展就是越好的，其一考慮此應用的投入產出比，換言之，是否值得投入這么多架構設計成本，其二架構設計也是具有一定的時效性的，IT速度太快了，今天的好東西未必是明天的好東西，年輕貌美的姑娘，總有變成老太婆那一天嘛,再者、越靈活的架構，就意味著存在更多的配置項，從某一方面，反而增加了系統的復雜度，最后、很多大型，成熟的應用，也并非一蹴而就，而是通過不斷的調整優化，不斷變更架構的。圣人也并非天生的，而是不斷的總結，提煉，優化，重構
?硬件方面使用高性能的小型機、存儲設備。使用極好的網絡帶寬
?物理分離Web Server和DB Server或者其他服務如：用戶認證服務
?緩存
ü數據緩存機制
ü頁面緩存機制
?物理分離業務模塊，單業務單獨部署一臺服務器
?部署多臺Web Server
?Web負載均衡-F5
?數據讀寫分離
?使用消息隊列進行各種應用間進行同步/異步計算
?應用間選擇合適的通信方式，通信協議
?Web分布式，應用分布式，數據分布式
?分布式的節點使用高性能服務器，小型機群,輔以高速網絡帶寬等
工具包
?進程管理器，CPU，內存，I/O
?日志：IIS日志，Windows日志，系統本身日志
?使用dotTrace,跟蹤方法執行時間，找出速度慢的方法，針對性優化
?Sql Profile跟蹤SQL耗時情況，針對性優化
?HttpWatch跟蹤請求耗時，以及發送和收到數據量
?Performance Count，使用計數器，統計相關性能指標
?CLRProfiler內存泄露檢測工具
?LoadRunner，壓力測試，發現性能瓶頸
其他補充
本文任何一處均可展開敘述，并輔以案例，但時間關系，希望工程中心有人幫忙完善或者以后有時間自己完善吧
總結
以上是生活随笔為你收集整理的系统性能调优的各个方面的全部內容，希望文章能夠幫你解決所遇到的問題。
