服務器壓力上不去緣由分析

百兆的帶寬在理論上1秒鐘能夠傳輸12.5MB的數據，可是考慮到干擾因素每秒傳輸只要超過10MB就比較正常啦。千兆帶寬每秒傳輸是100M。

http://www.cnblogs.com/candle806/archive/2011/04/02/2003828.html

經過分析，處於峯值只有網絡帶寬，爲90%以上，而對比此處的吞吐率值恰爲95MB/s左右，1Gbps的網絡帶寬傳輸速率爲128MB/s，從而代表因爲吞吐量過大，佔用了大量的帶寬資源，致使後續的虛擬用戶沒法獲得服務器的資源，而導致請求被拒絕。從最後的頁面響應時間來看，系統的壓力並無被承接到頁面上，而是因爲過大的吞吐量吞噬了網絡帶寬，致使最終沒法有效地完成測試任務。

http://www.xinfengit.com/200907/1848581.html

在性能測試過程當中，常常會遇到數據庫CPU資源利用率上不去

一、網絡帶寬問題

1.1被測試環境和lr用機都在百兆帶寬中

 

1.2被測試環境和lr用機不在同一帶寬中，被測試環境在千兆帶寬環境中，lr用機在百兆帶寬環境中

 

2.Controller機器在百兆帶寬中，被測試環境和lr壓力發生器在千兆或以上帶寬中

能夠查看被測試環境中的交換機的傳輸速率是100Mbps仍是1000Mbps。

TP-LINK TL-SF1016，傳輸速率：10/100Mbps

三、數據量問題

3.1網絡沒有問題，吞吐量甚至超過100M，可是後臺服務器資源仍是比較低。

數據庫中基礎數據量比較少，幾乎是空的數據庫，這樣數據庫CPU利用率也上不去

3.2數據庫中的數據量雖然比較多（100萬筆以上），可是在性能測試時真正用到的用戶所關聯的流水比較少，或者根本沒有關聯上流水。好比：150多萬的交易流水，目前用戶表有500個用戶號，其中有200個用戶號關聯到了流水錶中的數據，而測試時用到了50個用戶。數據庫CPU沒有上去，先要排除網絡和數據量的限制，而後要查看這50個併發用戶是否都關聯到了流水錶上？每一個客戶號關聯了多少流水（大於2000，小於10萬，太大的會不現實）？

 

四、JDBC鏈接池限制

以上網絡和數據量都沒有問題，則會考慮交易到數據庫的鏈接數是否有限制，和數據庫操做的那些交易的SQL請求根本沒有到達數據庫服務器。咱們能夠經過中間件的控制檯查看JDBC的最大容量（此鏈接緩衝池可容納的最大物理鏈接數）

4.1數據庫JDBC鏈接池限制，設置的原本就小，weblogic默認最大容量爲50。

 

4.2若是一臺應用服務器上是多路進行部署的話，查看各路JDBC鏈接是否均衡

 

五、應用程序問題

處理能力真的達到了極限==

 

六、性能測試腳本和數據問題