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