漫話：如何給女友解釋爲何雙11沒法修改收貨地址

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

QPS、TR、併發用戶數、最佳線程數等等這些都是系統對併發處理上有關的概念。能夠用來衡量一個系統的可用性等指標。web

RT

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

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

若是一個網站的RT很長的話，就會特別的影響用戶體驗。因此，RT是很重要的一個指標。也是各個網站須要重點優化的。服務器

拿一個遊樂園的例子來講明一下可能會比較容易理解，好比咱們去迪士尼樂園遊玩時候，大多數的項目都是須要排隊的。markdown

爲了讓遊客知道一個項目須要排隊多久才能玩上，迪士尼作了不少事情，好比他們有一個App，專門能夠提示每一個項目的預計排隊時間。再有就是每一個項目的排隊處都有一個小牌牌，上面寫着預計排隊時間。網絡

可是，這個時間並非憑空設定出來的，而是『計算』出來的。併發

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

一、迪士尼在每一個項目的入口處和出口處都會設置工做人員。
二、入口處工做人員隨機尋找遊客，給遊客一張小紙條，上面記錄着遊客開始排隊的時間。
三、入口處工做人員提醒遊客，項目遊覽玩以後，在出口處把小紙條交還給出口處的工做人員。
四、出口處工做人員在收到遊客的小紙條後，會用：當前時間-遊客開始排隊的時間 = 排隊時長。
五、爲了儘可能讓數據準確，通常會收集多個排隊時長以後，計算一個平均值。post

以上就是迪士尼的排隊時間計算法。其實，這也是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 ），而後倒到牀上就開始補覺了。

不過，在半睡半醒之間，我彷佛聽到女友還在埋怨：爲啥有的人能夠更換地址，我卻更換不了呢？

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