百兆的頻寬在理論上
1秒鐘可以傳輸12.5mb的資料，但是考慮到干擾因素每秒傳輸只要超過10mb就比較正常啦。千兆頻寬每秒傳輸是100m。
通過分析，處於峰值只有網路頻寬，為90%以上，而對比此處的吞吐率值恰為95mb/s左右，1gbps的網路頻寬傳輸速率為128mb/s，從而表明由於吞吐量過大，占用了大量的頻寬資源，導致後續的虛擬使用者無法得到伺服器的資源，而致使請求被拒絕。從最後的頁面響應時間來看，系統的壓力並沒有被承接到頁面上，而是由於過大的吞吐量吞噬了網路頻寬，導致最終無法有效地完成測試任務。
在效能測試過程中，經常會遇到資料庫cpu資源利用率上不去
1、網路頻寬問題
1.1被測試環境和lr用機都在百兆頻寬中
1.2被測試環境和lr用機不在同一頻寬中，被測試環境在千兆頻寬環境中，lr用機在百兆頻寬環境中
2.controller機器在百兆頻寬中，被測試環境和lr壓力發生器在千兆或以上頻寬中
可以檢視被測試環境中的交換機的傳輸速率是100mbps還是1000mbps。
tp-link tl-sf1016，傳輸速率：10/100mbps
3、資料量問題
3.1網路沒有問題，吞吐量甚至超過100m，但是後台伺服器資源還是比較低。
資料庫中基礎資料量比較少，幾乎是空的資料庫，這樣資料庫cpu利用率也上不去
3.2資料庫中的資料量雖然比較多（100萬筆以上），但是在效能測試時真正用到的使用者所關聯的流水比較少，或者根本沒有關聯上流水。比如：150多萬的交易流水，目前使用者表有500個使用者號，其中有200個使用者號關聯到了流水表中的資料，而測試時用到了50個使用者。資料庫cpu沒有上去，先要排除網路和資料量的限制，然後要檢視這50個併發使用者是否都關聯到了流水表上？每個客戶號關聯了多少流水（大於2000，小於10萬，太大的會不現實）？
4、jdbc連線池限制
以上網路和資料量都沒有問題，則會考慮交易到資料庫的連線數是否有限制，和資料庫操作的那些交易的sql請求根本沒有到達資料庫伺服器。我們可以通過中介軟體的控制台檢視jdbc的最大容量（此連線緩衝池可容納的最大物理連線數）
4.1資料庫jdbc連線池限制，設定的本來就小，weblogic預設最大容量為50。
4.2如果一台應用伺服器上是多路進行部署的話，檢視各路jdbc連線是否均衡
5、應用程式問題
處理能力真的達到了極限==
6、效能測試指令碼和資料問題
分析谷歌SEO關鍵詞長時間上不去之原因
谷歌seo非一朝一夕之功，需要我們充分遵循谷歌演算法及抓取規律，加上豐富的經驗和高質量的外鏈，這樣慢慢的才會有好的排名。當然了很多時候我們會發現實際操作過程中，關鍵詞排名的情況並沒有像我們預計的時間出現在我們想要達到的位置。究其原因，無外乎以下幾點 1 關鍵詞本身競爭非常激烈。儘管我個人一直認為谷歌...
伺服器壓力測試心得
最近完成了乙個伺服器框架，於是測試的他的qps，發現了乙個奇怪的問題，測試出來qps只有3w s，與前面說的10w s，有很大的差距。使用trace命令列印出glibc函式呼叫資訊，發現了大部分的時間程式處於鎖等待狀態，我開始懷疑認為是內部使用鎖占用太多時間。於是乎改為無鎖佇列。關於無鎖佇列已經記錄...
mysql伺服器查詢慢原因分析方法
mysql資料庫在查詢的時候會出現查詢結果很慢，超過1秒，專案中需要找出執行慢的sql進行優化，應該怎麼找呢，mysql資料庫提供了乙個很好的方法，如下 mysql5.0以上的版本可以支援將執行比較慢的sql語句記錄下來。1.需要使用開啟記錄查詢慢的sql記錄日誌 檢視慢查詢時間 show vari...