QPS和TPS是什麼

一、qps是什麼

QPS

QPS即每秒查詢率，是對一個特定的查詢伺服器在規定時間内所處理流量多少的衡量标準。

每秒查詢率

網際網路上，經常用每秒查詢率來衡量域名系統伺服器的機器的性能，即為QPS。

對應fetches/sec，即每秒的響應請求數，也即是最大吞吐能力。

計算關系：

QPS = 并發量 / 平均響應時間

并發量 = QPS * 平均響應時間

二、 TPS是什麼

TPS：Transactions Per Second（每秒傳輸的事物處理個數），即伺服器每秒處理的事務數。TPS包括一條消息入和一條消息出，加上一次使用者資料庫通路。（業務TPS = CAPS × 每個呼叫平均TPS）

TPS是軟體測試結果的測量機關。一個事務是指一個客戶機向伺服器發送請求然後伺服器做出反應的過程。客戶機在發送請求時開始計時，收到伺服器響應後結束計時，以此來計算使用的時間和完成的事務個數。

一般的，評價系統性能均以每秒鐘完成的技術交易的數量來衡量。系統整體處理能力取決于處理能力最低子產品的TPS值。

例如：天貓雙十一，一秒完成多少訂單

三、QPS與TPS的差別是什麼呢？

舉個栗子：假如一個大胃王一秒能吃10個包子，一個女孩子0.1秒能吃1個包子，那麼他們是不是一樣的呢？答案是否定的，因為這個女孩子不可能在一秒鐘吃下10個包子，她可能要吃很久。這個時候這個大胃王就相當于TPS，而這個女孩子則是QPS。雖然很相似，但其實是不同的。

四、如何提高單機qps

1、機器本身

1.1、cpu

1.2、記憶體

1.3、IO

1.4、網絡

2、程式代碼

3、邏輯架構

五、機器本身

分析的整體方法是由淺入深、層層深入，先看伺服器本身的名額有沒有遇到短闆，這個層面的分析也是相對最容易的，在配置層面（ulimit相關例如fd等）檢查沒有問題後，從下面四個方面進行分析。

1、cpu

cpu粗面上看有兩個名額，目前使用率和負載，使用率反應的是目前cpu使用的情況，而負載反應的是cpu任務的隊列情況，也就是說任務排隊情況。一般cpu使用率在70%以下，負載在0.7*核心數以下，cpu的名額就算正常。

也有例外情況得分析cpu的詳細名額，在運維小米消息系統的一個子產品時，伺服器用的是阿裡雲的ecs，整體cpu使用率不到30%，但業務就是跑不上量，和肖坤同學查後發現cpu0的軟中斷極高，單核經常打到100%，繼續查後發現網絡中斷都在cpu0上無法自動負載，和阿裡雲工程師确認後是所在機型不支援網卡多隊列造成的，最終定位cpu的單核瓶頸造成了業務整體瓶頸，如下圖：

cpu用滿的解決辦法簡單粗暴，在程式無bug的前提下，換機型加機器，cpu本身沒單獨加過。

2、記憶體

記憶體正常看的是使用率。這個在做cdn的小檔案緩存時遇到過，當時用的是ats，發現程式經常重新開機，業務跟着抖動，查日志後發現系統OOM了，當記憶體快要被占滿的時候，kernel直接把ats的程序給殺掉，然後報out of socket memory，留的截圖如下：

同樣，在應用層沒有優化空間時，那就加記憶體吧！！

3、IO

IO主要指硬碟，一般用iostat -kdx 1看各種名額，當 %util超過50%，且偶發到100%，這說明磁盤肯定是到瓶頸了。

要進一步檢視是否由于IO問題造成了系統堵塞可以用vmstat 1 檢視，下圖b對應因IO而block的程序數量。

這個在新浪做圖檔業務時遇到過，是一個源站的裁圖業務，設計上為了避免重複裁圖，在本地硬碟上存了一份近7天的資料，由于用python寫的，沒有像JVM那種記憶體管理機制，所有的IO都在硬碟上。有一天業務突然挂了，和開發查了2個多小時未果，中間調整了各種參數，緊急擴容了兩台機器依然不起作用，服務的IO高我們是知道的，檢視IO資料和曆史差不多，就沒往那方面深考慮，後邀請經驗頗多的徐焱同學參與排查，當機立斷将IO處理邏輯由硬碟遷到記憶體上，IO立馬下來了，服務恢複。

IO問題也得綜合的解決，一般從程式邏輯到伺服器都要改造，程式上把重IO的邏輯放在記憶體，伺服器上加SSD吧。

4、網絡

網絡主要是看出、入口流量，要做好監控，當網卡流量跑平了，那麼業務就出問題了。

同樣在運維圖檔業務時遇到過網卡跑滿的情況，是一個圖檔（小檔案）的源站業務，突然就開始各種5XX告警，查後5XX并無規律，繼而查網卡發現出口流量跑滿了，繼續分析，雖然網卡是千兆的，但按理就cdn的幾個二級回源點回源，不至于跑滿，将檔案大小拿出來分析後，發現開發的同學為了省事兒，将帶有随機數幾十M的apk更新包放這裡了，真是坑！！

網卡的解決方式很多，做bond和換萬兆網卡（交換機要支援），目前的情況我們後來改了業務邏輯，大于多少M時強制走大檔案服務。

六、程式代碼

當查了cpu、記憶體、IO、網絡都沒什麼問題，就可以和開發好好掰扯掰扯了，為什麼伺服器本身沒什麼壓力，量卻跑不上去，不要以為開發寫的程式都很優良，人無完人何況是人寫出來的程式呢？

很多時候就是程式或架構本身的問題跑不上去量，這個過程運維還是要協助開發分析代碼邏輯的，是不是程式cpu和記憶體使用的不合理？是不是線程池跑慢了？是不是用的同步沒改異步？要把代碼執行的所有邏輯環節一一分析，找出瓶頸點，解決掉，常用的方法是日志埋點或者用專業的apm工具做鑽取分析。

如果暫時不好解決，可以考慮是不是可以跑一下多執行個體。

七、邏輯架構

發展至今，微服務架構設計已成為大型網際網路應用的标配，各子產品間通過HTTP、RPC等互相依賴調用，如果查完伺服器、程式依然沒有問題，再往深處走就得協同開發分析系統架構了，這也是微服務系統下的一個特色，不是因為伺服器或者程式本身bug造成了業務瓶頸，而是某個子產品的短闆造成了整個業務吞吐量上不去，這個很好了解，子產品中甚至有很多接口用的是公網外部服務，慢是正常的。

具體分析上，從一次完整的請求分析一遍所有子產品調用，從頭到尾理一遍外部依賴的上下遊資源和調用關系，外部資源包括api接口、DB、隊列等，然後在每個點做埋點日志，将資料進行分析，我們線上上用這種方法不知道分析出了多少瓶頸。

如果某個子產品沒有做好降級熔斷，再加上程式的執行是堵塞的，一個子產品慢拖累整個請求，進而QPS上來後拖誇整個系統的例子很多，在這種情況下，如果瓶頸子產品依賴的接口是别的部門或外網資源，加多少伺服器都解決不了問題，進行改造吧。