QPS、TPS、RT概念是什么

本篇內容介紹了“QPS、TPS、RT概念是什么”的有關知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領大家學習一下如何處理這些情況吧！希望大家仔細閱讀，能夠學有所成！

一、概述

分布式、微服務、Service Mesh目前都是大家耳熟能詳的詞語了，現在隨便一個互聯網公司說出來大家都是在搞微服務。

但我們搞來搞去，怎么樣來衡量一個應用當前的狀態到底是怎么樣的？到底需不需要擴容？是需要橫向擴容還是進行項目重構？

這時候我們就需要一堆監控指標來協助我們進行分析當前的應用狀態，以便在某些事故發生前進行資源上的調配或優化。

下面咱們就來說道說道這幾個重要的指標，一定要記牢，不管面試還是自己用都是必須滴。

要牢記一點，所有的指標都是根據時間單位來算的，比如每秒XX、每分鐘XX，要記住這個大前提，下面咱們都按秒來算。

二、指標

1、QPS（Queries Per Second）

概念：服務器每秒處理查詢次數，是一臺服務器每秒能夠處理的查詢次數。用戶發起查詢請求到服務器做出響應這算一次，一秒內用戶完成了50次查詢請求，那此時服務器QPS就是50。

2、TPS （Transactions Per Second）

概念：服務器每秒處理的事務數，一個事物是用戶發起查詢請求到服務器做出響應這算一次。納尼？這難道不是QPS的概念嗎？劃重點，這里就要說清楚一個概念了，在針對單接口，TPS可以認為是等價于QPS的，如訪問 ‘order.html’ 這個頁面而言,是一個TPS。而訪問 ‘order.html’ 頁面可能請求了3此服務器（如調用了css、js、order接口），這實際就算產生了三個QPS

所以，總結下就是，在針對單接口的時候TPS = QPS ,否則QPS就要看實際的請求次數了。

2、RT（Res（onse Time）

概念：響應實際，就是從客戶端請求發起到服務器響應結果的時間。RT這個參數是系統最重要的指標之一，它的大小直接反應了當前系統的響應狀態。基本和咱們用戶體驗息息相關，現在好一點監控系統一般都有三個RT，即平均、最大、最小。

一般系統RT 100ms 以內是比較正常的，300ms 勉強可以接受，1s的話再加上一些其他的外因，給用戶的體驗就是實實在在的不爽了。

3、并發數

概念：系統能同時處理的請求的數量，很多人經常會把并發數和TPS理解混淆。舉例，請求一個index.html 頁面，客戶端發起了三個請求（css、js、index接口）,那么此時TPS =1 、QPS =3 、并發數 3。

SO，計算公式 ： QPS=并發數/RT || 并發數=QPS*RT

4、吞吐量（Throughput）

概念：每秒承受的用戶訪問量，吞吐量（系統能承受多少壓力）和當前請求對CPU消耗、內存、IO使用等等緊密相關。單個請求消耗越高，系統吞吐量越低，反之越高。

一個系統的吞吐量和其TPS 、QPS、并發數息息相關，每個系統針對這些值都有一個相對極限值，只要其中某一個達到最大，系統的吞吐量也就到達極限了。如此時壓力繼續增大，系統的吞吐量反而會下降，原因是系統超負荷工作，各種資源切換等等的消耗導致系統性能下降。

關系：

所以，理解上面幾個關系后，就可以推算出：

QPS（TPS）= 并發數/平均響應時間

5、PV（Page View）

概念： 即每個頁面的瀏覽次數，用戶每次刷新就算一次。

6、UV（Unique Visitor）

概念：獨立訪客數，每天訪問的用戶數，此數據需要根據用戶唯一標識進行去重。

7、Load（系統負載）

概念：此數據指的是Linux系統的負載情況，也就是咱們平時所用Top命令時，最上面顯示的數據信息( load average: 0.1, 0.2, 0.5)。此時會顯示1分鐘、5分鐘、15分鐘的系統平均Load，很顯然load average 的值越低，你的系統負荷越小。

簡單的說下這個值應該怎么看，如果你是單核cpu,那此值為1的時候就是系統已經滿負荷狀態了，需要你馬上去解決。但實際經驗告訴我們，當系統負荷持續大于0.7的時候（也就是70%），就需要你馬上來解決問題了，防止進一步惡化。

為什么需要三個值 load average: 0.1, 0.2, 0.5，其實就是給你個參考。比如只有1分鐘的是1，其他倆都是0.1，這表明只是臨時突發的現象，問題不大。如果15分鐘內，系統負荷都是1或大于1，那表明問題持續存在啊。所以你應該主要觀察15分鐘的系統負荷。

“QPS、TPS、RT概念是什么”的內容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業相關的知識可以關注億速云網站，小編將為大家輸出更多高質量的實用文章！