系統性能調優的各個方面

概述

Ø性能優化的思路

首先是較爲精準的定位問題，藉助於相應的工具包，分析系統性能瓶頸在哪，在根據其性能指標，以及所處於層級決定選擇優化的方式方法。在選擇優化的方式方法時，你們能夠參照如下章節調優方法，架構優化遞進，進行正確的，有針對性，有步驟的優化。可能會發現部分指導思想或許有相悖嫌疑，大可沒必要較真，系統優化的過程自己就是一個不斷分離+共享的組合拳，至於具體選擇哪一種優化方式，根據具體需求來定，但大型應用發展的整體思路是不斷分離，在經過索引（非數據庫）進行關聯起來，

切記：優化必定要對系統進行細緻的望聞問切，找到性能問題根源切入點，而不被表象迷糊，對症下藥，發現病症所在的醫生並不比操做手術刀的醫生水平差。本文有工具包一章節，對於須要作優化的人員，須要熟悉，他就是咱們診斷所用的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，壓力測試，發現性能瓶頸

其餘補充

本文任何一處都可展開敘述，並輔以案例，但時間關係，但願工程中心有人幫忙完善或者之後有時間本身完善吧