系統性能調優吐血總結經驗分享
性能優化的思路
首先是較為精準的定位問題，借助于相應的工具包，分析系統性能瓶頸在哪，在根據其性能指標，以及所處于層級決定選擇優化的方式方法。在選擇優化的方式方法時，大家可以參照以下章節調優方法，架構優化遞進，進行正確的，有針對性，有步驟的優化。可能會發現部分指導思想或許有相悖嫌疑，大可不必較真，系統優化的過程本身就是一個不斷分離+共享的組合拳，至于具體選擇哪種優化方式，根據具體需求來定，但大型應用發展的總體思路是不斷分離，在通過索引(非數據庫)進行關聯起來，
切記：優化一定要對系統進行細致的望聞問切，找到性能問題根源切入點，而不被表象迷糊，對癥下藥，發現病癥所在的醫生并不比操作手術刀的醫生水平差。本文有工具包一章節，對于需要做優化的人員，需要熟悉，他就是我們診斷所用的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，壓力測試，發現性能瓶頸
其他補充
源文檔下載：http://down.51cto.com/data/220108
【編輯推薦】
