經常我們都會抱怨手機好卡、網頁打不開等...遇到這種情況還是要淡定，這個對於程序猿來說就是一次大顯身手的機會，可以有機會解刨什麼造成程序跑的慢導致用戶體驗不好。用戶的投訴那是致命的，如果處理不好就會導致客戶流失。

系統出現性能問題，要發現問題所在其實是一個很考量個人能力的事情，因為它要求你有全面的知識或者協調能力，因為你對整體把握或者認識不足查找最終的原因可能就需要花費更多的時間，時間就是金錢還真不是吹的，用戶是等不起的。。。我們還是需要提升自己的綜合能力。

性能的參考指標：

執行時間：一段代碼從開始運行到運行結束，所使用的時間；

CPU時間：函數或者線程佔用CPU的時間；

內存分配：程序在運行時佔用的內存空間；

磁碟吞吐量：描述I/O的使用情況；

網路吞吐量：描述網路的使用情況；

響應時間：系統對某用戶行為或者時間做出響應的時間。響應時間越短，性能越好。

木桶原理與性能瓶頸：

一隻木桶盛水的多少，並不取決於桶壁上最高的那塊木板，而是取決於桶壁上最短的那塊。根據木桶原理，系統的最終性能取決於系統中性能表現最差的組件。因此為了提升系統整體性能，必須對系統中表現最差的組件進行優化，而不是對系統中表現最好的組件進行優化。

最有可能成為系統瓶頸的計算機資源如下：磁碟I/O、網路操作、CPU、異常、資料庫、鎖競爭、內存。

Amdahl定律

加速比定義：加速比=優化前系統耗時/優化後系統耗時

根據該定律，使用多核CPU對系統進行優化，優化的效果取決於CPU的數量以及系統中的串列化程序的比重。CPU數量越多，串列化比重越低，則優化效果越好。僅提高CPU數量而不降低程序的串列化比重，也無法提高系統的性能。

性能優化層次：

1.設計調優：是需要在軟體開發之前進行，架構師就應該評估系統可能存在的各種潛在問題，並給出合理的設計方案。是一個質的優化。設計人員必須熟悉掌握常用的軟體設計方法、設計模式、基本組件和常用優化思想，並將其有機地集成在軟體系統中。

2.代碼調優：主要是對代碼的改進和優化。

3.JVM調優：

4.資料庫調優：首先對應用層的SQL語句進行優化；其次對資料庫進行優化；再次對資料庫軟體進行優化；

5.操作系統調優：針對操作系統的優化，還是需要考量知識的全面。

優化的步驟：

首先需要明確的性能目標，清楚地指出優化的對象和最終的目的。其次，需要在目標平台上對軟體進行測試，通過各種性能監控和統計工具，觀察和確認當前系統是否已經達到相關目標，若已經達到，則沒有必要進行優化；若當前系統性能尚未達到優化目標，則需要查找當前的性能瓶頸。

系統優化注意事項：

軟體優化需要在軟體功能、正確性和可維護性間取得平衡，而不應該過分地追求軟體性能。性能調優必須有明確的目標。不要為了調優而調優，如果當前程序並沒有明顯的性能問題，盲目地進行調整，其風險可能遠遠大於收益。優化後必須進行全流程的覆蓋測試，以防止潛在的BUG。系統優化個人覺得就是在尋找一個平衡點，對客戶來說系統可用且穩定、對資源提供者來說以最小的代價換區最大的利潤。

推薦閱讀：

相关文章