作者：漫話程式設計  

來源：漫話程式設計

2018年11月11日上午11點，我拖著疲憊身軀回到家中，準備美美的睡上一覺，洗去身上值班一宿而帶來的疲憊。突然想到之前有交代女朋友讓她幫我搶東西，不知道怎麼樣了。

QPS、TR、併發使用者數、最佳執行緒數等等這些都是系統對併發處理上有關的概念。可以用來衡量一個系統的可用性等指標。

RT

響應時間(Response Time)，是指從客戶端發一個請求開始計時，到客戶端接收到從伺服器端返回的響應結果結束所經歷的時間。

當我們評價一個網站的"快"和"慢"的時候，其實說的就是他的RT時間的長和短。當我們訪問某個網站，有時候我們會說這個網站很"卡"，其實言下之意說的就是這個網站的RT很長。

如果一個網站的RT很長的話，就會特別的影響使用者體驗。所以，RT是很重要的一個指標。也是各個網站需要重點優化的。

拿一個遊樂園的例子來說明一下可能會比較容易理解，比如我們去迪士尼樂園遊玩時候，大多數的專案都是需要排隊的。

為了讓遊客知道一個專案需要排隊多久才能玩上，迪士尼做了很多事情，比如他們有一個App，專門可以提示每個專案的預計排隊時間。再有就是每個專案的排隊處都有一個小牌牌，上面寫著預計排隊時間。

但是，這個時間並不是憑空設定出來的，而是『計算』出來的。

迪士尼的排隊時間計算方法：

1、迪士尼在每個專案的入口處和出口處都會設定工作人員。  
2、入口處工作人員隨機尋找遊客，給遊客一張小紙條，上面記錄著遊客開始排隊的時間。  
3、入口處工作人員提醒遊客，專案遊覽玩之後，在出口處把小紙條交還給出口處的工作人員。  
4、出口處工作人員在收到遊客的小紙條後，會用：當前時間-遊客開始排隊的時間 = 排隊時長。  
5、為了儘量讓資料準確，一般會收集多個排隊時長之後，計算一個平均值。

以上就是迪士尼的排隊時間計演算法。其實，這也是RT的計算方法。在一個請求開始的時候記錄時間，請求結束的時候再記錄時間，兩個時間的差值，就是RT了。

迪士尼的一個專案的RT包含了多個時間段：排隊時間、聽專案講解時間、專案準備時間、專案遊玩時間等。

伺服器響應時間也有多部分組成，一般包含：請求傳送時間、網路傳輸時間和伺服器處理時間等三部分。

QPS 

QPS，指的是系統每秒能處理的請求數(Query Per Second) ，在Web應用中我們更關注的是Web應用每秒能處理的request數量。這個是衡量系統性能的重要指標。有時候，我們也稱之為吞吐量。

QPS和RT幾乎總是成對出現的。當我們評價迪士尼的一個專案的好壞的時候，通常會包含這幾個指標：是否好玩、遊玩時長以及可以同時容納多少人。

這個可以同時容納多少人，就可以簡單的理解為QPS。很大程度上，一個專案同時可以容納多少人，其實會大大的影響遊客的遊玩時長。

所以，QPS和RT之間是有著一定的關係的：

RT= 併發數/QPS
QPS= 併發數/RT

雖然上面的等式看上去，在併發數一定的情況下，想要提升QPS的話就只能降低RT。但其實並不是，以上只是QPS的計算方法。想要提升QPS往往有很多手段。

就像想要提升遊樂設施的吞吐量，最首先想到的辦法就是升級裝置，比如增加遊樂場地的面積，增加裝置的座位數目，增加排隊的隊伍個數等。

在計算機系統中，想要提升QPS，主要可以在CPU、記憶體等硬體上面下功夫，比如提升CPU利用率、增加CPU數目、提升記憶體等。

和QPS類似，還有個TPS的概念，這裡就不做展開了，本文中提到的吞吐量，泛指QPS和TPS，不做詳細區分。

併發使用者數

併發使用者數指的就是同時跑到一個專案前面排隊的人數。  

關於併發使用者數有兩種常見的錯誤觀點。

一種錯誤觀點是把併發使用者數量理解為使用系統的全部使用者的數量；（比如迪士尼的飛躍地平線專案一天可能會接納50萬人，我們不能說這個50萬就是併發使用者數）

還有一種錯誤觀點是把使用者線上數量理解為併發使用者數量。（比如晚上六點的時候，迪士尼的飛躍地平線專案排隊加觀看人數共有1萬人，我們不能說這個1萬就是併發使用者數）

併發使用者數量的正確理解為：在同一時刻與伺服器進行了互動的線上使用者數量。（我們說，晚上六點的時候，共有8000人正在和正在排隊使用飛躍地平線這個專案。這才是併發使用者數）

拿系統來說，我們說淘寶詳情頁的併發使用者數，其實說的是同一時刻請求檢視詳情頁的使用者個數。有些使用者雖然也在瀏覽詳情頁，但是它並沒有在併發時刻和系統有互動，這就不算的。

最佳執行緒數

最佳執行緒數指的就是一個專案最多可以容納的人數，這裡的容納可以包含排隊的人數。  



迪士尼每新開一個場館或者一個遊戲專案的時候，都會是一個試運營的階段。在試運營階段，通過不斷調整併發使用者數來觀察整個場館或者專案的執行情況。

除了上線新場館和新專案以外，有的是在節假日之前也會有一些類似的實驗。

這和計算機軟體的壓測很像。就是不斷的提高請求數目，來觀察系統的QPS和系統的其他指標，如CPU情況、記憶體情況等。

效能壓測的情況下，起初隨著使用者數的增加，QPS會上升並對CPU等影響不大，當到了一定的閥值之後，使用者數量增加QPS並不會增加，或者增加不明顯，同時CPU Load有飆高、記憶體佔用大等情況發生。隨之而來的伴隨著請求的響應時間大幅增加。這個閥值我們認為是最佳執行緒數。

如果併發請求數目，超過了系統的最佳執行緒數，那麼就會導致激烈的資源競爭，隨著資源的匱乏甚至枯竭，整個系統也就面臨著災難。

說完，也不管女朋友的反應，我順手給她扔了一個連結（ http://www.techug.com/post/10-tips-of-web-app-performance.html ），然後倒到床上就開始補覺了。

不過，在半睡半醒之間，我似乎聽到女朋友還在埋怨：為啥有的人可以更換地址，我卻更換不了呢？

我知道，下次肯定要給她講熔斷、限流和降級等知識了。

-END-

 近期熱文：

關注我

點選“閱讀原文”，看本號其他精彩內容