系統性能優化的幾個方面

過去

　　很早以前，做管理系統，對性能體會并不是特别明顯。因為一些使用者非常聰明，會通過調整自己的使用方式來适應系統的處理能力。現在想起來，有環境的原因也有能力的原因，沒有做好性能的事情，覺得有些好笑也有些遺憾。

　　現在做的程式，對響應速度、處理能力都有一定的要求，而且這些名額直接和效益挂鈎。這個時候，性能問題就随着系統的運作不斷顯現出來，并在運作過程中左右一項重要任務不斷改進、調優。

　　性能優化的過程是一種辛苦又有趣的挑戰。

　　改進總是在事關利害的時候才會有推動力。

來自業務上的簡化

　　很多時候，自己是一個理想主義者，公司的其他一些也是，是以在系統設計時：總試圖考慮周全，試圖具備很強的擴充性，試圖一勞永逸。事實是，在沒有對業務成竹于胸、對設計沒有深刻立即的時候，很難做到。是以往往過度設計、過度開發。

　　多做事情，不是好事情，尤其是那些高頻度執行的業務流程上，影響尤其嚴重。多一個環節，都是意味着多消耗計算資源。

　　很早前，我們做的程式在結算上，要求對交易賬号三方進行資金劃撥（一方減少，另外一方增加，第三方傭金增加），要記錄資金變動明細，要有事務保護。這業務，在交易量不大的情況下，沒有問題；小幅度的性能提升也可以通過提升硬體配置來解決。但是對于我們，營運一段時間後，性能真的很難再提升：１、業務邏輯寫得很複雜，改動風險很大，２、所有瓶頸在資料庫上，事務經常失敗

　　經過很長時間的觀察，我們發現業務并沒有朝預想的方向發展，我們并不需要三方劃賬，隻需要單方扣款就可以了；我們也發現，資金做好變動日志就可以了，事務也可以不需要。這個業務調整确定下來後，砍掉了這個子產品６成的代碼，單台的服務性能大幅提高。

　　事後感歎，真的想多了，業務沒有想的複雜。業務上的簡化，比其他方面的優化，我認為更加有效，也更加樂意去做：

　　1. 可以删掉很多無用的東西，維護簡單了，

　　2. 以前不爽的代碼終于可以丢掉了

部署上的優化

　　業務總是在上升的，單台伺服器，總會有一個上限。這是常理，但在開始做程式的時候，隻是想過，并有做預案。那時的想法是先完成業務，再考慮性能（這個政策，仁者見仁，智者見智）。是以解決方法必定是增加硬體。

　　要增加硬體，首先需要硬體，首先要考慮系統自身的伸縮性問題。對之前開發的大而全的程式來說，首先要做的拆解。将業務流程拆解成多個獨立的環節，每個環節自成一體，獨立運作，環節之間通過網絡通訊。業務流程拆解帶來諸多好處：降低整體的複雜度，學習、開發、維護成本會大大下降。

　　系統具備一定伸縮性後，就可以調整部署，我的了解是有兩個次元：

　　1. 不同環節部署到不同的伺服器上，分攤壓力

　　2. 關鍵環節多套部署，增加處理能力

　　通過部署，基本上能解決性能的問題。在這個過程中，尤其是第二個次元，資料唯一性是一個技術單點。

　　就現在的情況看，增加硬體的成本，還是遠低于開發、維護的人力成本的，所有這個方式的性能優化，是運維喜歡幹的。

來自資料庫上優化

　　資料庫的優化空間，還是挺大的，主要表現在表索引的合理使用、表字段設計、表關聯查詢、事務。

　　個人認為：

　　１、對于性能要求的程式，盡量避免使用事務、和表關聯。

　　２、好的索引能夠很大程度上提高速度

　　３、如果資料量大，要考慮表分區

　　一些編碼的人，對資料庫了解不多，沒有連主鍵、索引的都沒有，也時常發生。是以優化這個，是程式員，尤其懂資料庫的程式員喜歡幹的事情。時常聽到一些牛人将一些耗時巨大的資料計算，瞬間提升數百、數千倍。

來自程式實作上優化

　　一般公司的程式，隻是完成某一些業務而且，沒有什麼大不了的技術攻關，所有也談不上什麼高深的技術。而我們寫的程式，經常會因為各種各樣的原因，多做一些沒用的事情：

　　１、沒有用的ｆｏｒ循環

　　２、可以在一個循環裡面搞定的，做了多個循環

　　３、一個事情反複做，通常是代碼互相調用（因為計算結果沒有共享或傳遞）

　　這個事情，程式員會比較喜歡做。程式員每隔一段時間都會回頭看自己的過去，每每發現以前的幼稚表現，都有沖動去修正一下。

來自硬體的提升

　　換一個性能高一點的裝置。想想比較簡單，實際上也是需要有很專業的測試，才知道硬體是否真的合适。

　　

一些小經驗

IIS行嗎

　　在開發現在這個程式的時候，有人提醒我們IIS容易崩潰，不穩定，性能不行。

　　在系運作之初，我們的确也是碰到這兩個問題，也懷疑IIS是否真的不行。遇到記憶體消耗居高不下、線程消耗居高不下、CPU滿負荷，總是間歇性崩潰。

　　随着問題的逐漸解決，我們發現，其實大部分原因是代碼編寫不當，一小部分是不了解IIS的運作機制。目前系統還能夠持續穩定運作。

記憶體問題

　　.Net有垃圾回收機制，但也不能濫用，少New一點也許會好點

　　.Net的垃圾回收，并不是一個對象釋放了，就馬上會回收的，記憶體占用高，不代表就是真的消耗了那麼多

線程消耗

　　多線程是解決一些性能問題的良方，但是線程是有成本的，線程太多，CPU會把時間浪費線上切換上

　　對于IO密集型的，最好采用異步的方式。同步方式意味着一個線程大部分時間消耗在等待上。

　　對于cpu密集性的，處理更新增加硬體投入，好像沒有辦法。

　　不要把ThreadPool中的線程耗光了，不然IIS就不響應了：１、asp.net也用這個線程池；2、每秒隻會建立2個新線程；

CPU滿負荷

　　多數情況下，是死循環了

　　還有就是做了一些多餘的事情

MsSql之Nolock

　　通常，在ＭＳＳＱＬ中，有Nolock的提示符，表示允許髒讀，這種情況下，避免使用鎖，非常有效。多數情況下，我們的一些資料并沒有那麼嚴格要求，即便是髒讀，也沒有什麼關系。

MsSql之with（rowlock)

　　使用Update語句，一些時候是明确隻更新單行的，尤其是狀态轉換的，使用rowlock，會好一些（感覺，沒有測試确認過）。

轉載于:https://www.cnblogs.com/t-lz/p/4364904.html