ps:本文提出的數值不做為判斷標準,數值的大小是根據介面的業務而定的,不同的場景會有的不同的標準.
首先應該關注介面的rps/跟平均耗時,這邊壓測工具以locust做為資料提供工具(效能工具很多以適合自己為標準), 在使用者上來後關注rps是否滿足1000以上,然後關注介面耗時是否在100ms之內,複雜介面可視情況在200ms之內,最高不超過300m(數值方面根據你的壓測服務而定沒有統一標準),這邊的檢視介面耗時有兩種:第一種是有網路延遲,第二種是沒有網路延遲,有網路延遲的直接在locust上檢視如下圖,第二種伺服器本地處理的耗時，不包括網路延時，在kibana日誌平台上看(監控後台日誌平台)
在滿足第一條的關注的指標資料後,在關注資料訪問次數,資料庫負載,一般第一條指標合格的話第二條也會達到合格標準,到後台監控日誌平台,檢視被壓測介面平台訪問資料庫連線次數,這個數值的最大值低於30以下屬於正常，低於50屬於警戒，超過50一般就是設計有問題.
ps:locust 注意事項
每個task 只能有單個請求,不然實際的rps 跟伺服器的處理的請求數是不一致的,多個請求在同乙個task裡 locust得出是你這個任務裡的rps.所以要獲取準確的介面rps 應該單個任務但是介面,例如以下截圖:
伺服器的rps:
這次所有請求的平均耗時,以及他的平均最高95%(這邊是平均值)
關於效能測試的測試型別
模擬系統在不同負載條件，系統的各項效能指標是否良好 關注點 首要是最佳使用者數量和最大使用者數量，然後還要關注各項效能指標的值 模擬負載超出了最大值之外的情況，看系統如何崩潰，目的是據此尋找改善使用者體驗的方案 關注點 系統在極限壓力時崩潰的原因 關注點 系統的最大使用者數，資料庫的儲存條目數量，表...
js 關於效能優化的一些學習總結
效能優化的方法有 1 減少http請求 合併css js，使用css sprite等 2 壓縮css js 4 減少dom操作，dom操作很消耗效能，另外注意htmlcollection和nodelist。這兩個物件是動態的，每次訪問都會進行一次查詢。在迭代中避免重複訪問。歷史上的dom集合介面。主...
效能測試關注的指標
效能測試關注的點 1 客戶端響應時間 2 throughput 吞吐量 系統吞吐量幾個重要引數 qps tps 併發數 響應時間 qps tps 每秒鐘request 事務 數量 併發數 系統同時處理的request 事務數 理解了上面三個要素的意義之後，就能推算出它們之間的關係 qps tps 併...