系統負載

• •系統CPU利用率

如果系統的CPU使用率已經很高，說明我們的系統是個計算度很復雜的系統，這時候如果QPS已經上不去了，就需要趕緊擴容，通過增加機器分擔計算的方式來提高系統的吞吐量。

• •系統內存

如果CPU使用率一般，但是系統的QPS已經負載不了了，說明我們的機器並沒有忙於計算，而是收到其他資源的限制，如內存或者io。這時候首先看下內存是不是已經不夠了，如果內存不夠了，那就趕緊擴容了。

針對Java項目來說，JVM中Heap信息也是內存的一個直接反應，如Java的老年代的內存占比，是否發生Full GC的情況等。

• •系統IO

系統的IO一般是和CPU使用率相反的，CPU利用率高的時候，IO使用率就不大，而IO使用率高的時候CPU一般利用率不高。

• •網絡帶寬(可支持的網絡鏈接數)

當我們自身系統的網絡帶寬被占用完畢的時候，相當於把系統的入口和出口給堵死了，這時候外界的需求排不進來了，QPS自然上不去。

在我們的系統中時常會使用連接池的方式來連接DB，也會使用HTTP連接池的方式向依賴系統發起服務，或者使用線程池的方式提供給其他服務使用。很多時候因為系統的本身連接池自身有最大連接數的限制，會導致系統連接數耗盡，單系統其他資源依然屬於正常情況。這時候可以適當增加連接數的方式，來增加系統的吞吐能力，但這種方法需要慎重，因為過多的連接池，會更快的消耗系統資源，並且會將壓力傳遞給依賴系統。

依賴系統的性能

• •DB 性能

DB性能很多時候是系統的根本，因為一旦DB出現了大問題，不單單會導致一個系統出問題，很可能會導致所有依賴此DB的系統出現業務邏輯問題。

一般開發在實踐中，遇到最多的問題就是不當的SQL導致DB讀寫性能很低，如未使用索引的讀寫SQL;如數據庫表不適當的鎖范圍;另外，如果DB本身的讀寫已經達到了自身的限度，這時候可以考慮更換機器，更換系統的硬盤，或者增加讀庫等方法，但這方面的優化內容非常復雜，在後面會有專門的篇幅來討論。

• •依賴服務的性能 依賴別人的服務，很多不確定其系統性能如何，在可能情況下，可以讓下游系統緊急擴容的方式來解決其自身性能問題;但對於自身系統而言，可以采用快速失敗和接口降級的方式來實現。

如果上面所說的系統自身指標和依賴系統的指標都相對正常，但系統的QPS依然無法負載，說明系統內部出現問題，如系統被阻塞了。

在進行系統優化之前需要進行Profile測試分析，根據2：8原則來說，20%的代碼耗了你80%的性能，找到那20%的代碼，你就可以優化那80%的性能。