建站
咨詢
售后
建站咨詢
新聞中心
你開發(fā)了一個服務(wù)，調(diào)用它，它做了一些事情并返回結(jié)果。那么，它需要花多長時間？為什么有時候它花的時間比用戶期望的要長？在這篇文章中，我將從最基礎(chǔ)的講起，然后逐步介紹一些標(biāo)準(zhǔn)的術(shù)語，同時著重強(qiáng)調(diào)一些需要知道的關(guān)鍵點(diǎn)。
創(chuàng)新互聯(lián)建站服務(wù)項(xiàng)目包括西寧網(wǎng)站建設(shè)、西寧網(wǎng)站制作、西寧網(wǎng)頁制作以及西寧網(wǎng)絡(luò)營銷策劃等。多年來，我們專注于互聯(lián)網(wǎng)行業(yè)，利用自身積累的技術(shù)優(yōu)勢、行業(yè)經(jīng)驗(yàn)、深度合作伙伴關(guān)系等，向廣大中小型企業(yè)、政府機(jī)構(gòu)等提供互聯(lián)網(wǎng)行業(yè)的解決方案，西寧網(wǎng)站推廣取得了明顯的社會效益與經(jīng)濟(jì)效益。目前，我們服務(wù)的客戶以成都為中心已經(jīng)輻射到西寧省份的部分城市，未來相信會繼續(xù)擴(kuò)大服務(wù)區(qū)域并繼續(xù)獲得客戶的支持與信任！
首先，我們需要一種方式來度量時長，還需要理解兩個完全不同的度量角度。從調(diào)用服務(wù)的外部用戶角度來看，我們需要度量響應(yīng)時間。從服務(wù)處理請求的角度來看，我們需要度量服務(wù)時間。這就引出了第一個關(guān)鍵點(diǎn)，人們常常分不清一些指標(biāo)。
對于用戶來說是響應(yīng)時間（Response Time），對于服務(wù)來說是服務(wù)時間（Service Time）。
在真實(shí)世界里，每一個處理過程都包含了很多步驟，每個步驟都需要占用一些時間。步驟占用的時間叫作駐留時間（Residence Time），駐留時間由等待時間（Wait Time）和服務(wù)時間組成。以用戶登錄 App 為例，一個用戶登錄手機(jī) App，App 會調(diào)用 Web 服務(wù)進(jìn)行用戶認(rèn)證。為什么有時候會很慢？按理說，每一次手機(jī)上生成請求的時間、將請求傳輸給 Web 服務(wù)的時間、查詢用戶的時間、返回結(jié)果并顯示下一個屏幕的時間應(yīng)該是一樣的。造成響應(yīng)時間長短不一的是排隊(duì)時間，也就是等待正在處理其他請求的資源。從手機(jī)到認(rèn)證服務(wù)器之間的網(wǎng)絡(luò)傳輸需要經(jīng)過很多跳，每一跳前面都有等待被發(fā)送的數(shù)據(jù)包。如果隊(duì)列是空的或者隊(duì)列很短，那么響應(yīng)速度就很快，如果隊(duì)列很長，響應(yīng)就很慢。當(dāng)請求達(dá)到服務(wù)器時，也需要排隊(duì)等待 CPU 處理。如果需要查詢數(shù)據(jù)庫，還需要排到另一個隊(duì)列里。
排隊(duì)等待是導(dǎo)致響應(yīng)時間增加的主要原因。
監(jiān)控工具會提供一個叫作吞吐量（Throughput）的指標(biāo)，用來度量處理頻度。在某些情況下，我們也會得到一個叫作到達(dá)率（Arrival Rate）的指標(biāo)，用于度量到達(dá)服務(wù)器的請求的速率。在理想情況下，比如一個具有穩(wěn)定工作負(fù)載狀態(tài)的 Web 服務(wù)，一個請求對應(yīng)一個響應(yīng)，那么吞吐量和到達(dá)率是一樣的。不過，重試和錯誤會導(dǎo)致到達(dá)率增加，但吞吐量不會增加。對于快速變化的工作負(fù)載或者需要長時間處理的請求（比如批次作業(yè)），會出現(xiàn)到達(dá)率和吞吐量之間的不均衡，并產(chǎn)生更為復(fù)雜的請求模式。
吞吐量是指已經(jīng)成功處理完的請求數(shù)量，它跟達(dá)到率是不一樣的。
我們可以通過一些跟蹤系統(tǒng)（比如 Zipkin 或 AWS X-Ray）來跟蹤單個請求流，不過我們這里討論的是大量請求以及它們之間的交互關(guān)系。我們通過固定的時間間隔來度量均值，時間間隔可以是秒、分鐘、小時或天。計(jì)算均值需要足夠多的數(shù)據(jù)，一般來說每個均值至少需要 20 個數(shù)據(jù)點(diǎn)。
如果請求不是很頻繁，請選擇一個至少包含 20 個請求的時間間隔，這樣才有可能得到比較有用的信息。
如果選擇的時間間隔太大，會導(dǎo)致工作負(fù)載的變化被隱藏掉。例如，對于視頻會議系統(tǒng)來說，大部分會話會在一個小時的頭一分鐘左右啟動，并且很容易在這些時間段達(dá)到峰值，讓系統(tǒng)發(fā)生過載，如果時間間隔是小時，這些信息就會丟失掉。所以，對于這種情況，時間間隔設(shè)為秒更為恰當(dāng)。
對于變化快的工作負(fù)載，可以使用秒級的均值。
監(jiān)控工具各種各樣，但一般很少會直接告訴我們等待隊(duì)列有多長或有多少并發(fā)度可用來處理隊(duì)列。大多數(shù)網(wǎng)絡(luò)每次只傳輸一個數(shù)據(jù)包，但 CPU 的每個核心或 vCPU 可以并行處理隊(duì)列里的任務(wù)。數(shù)據(jù)庫通常有一個固定的最大連接數(shù)，用來限制并發(fā)度。
對于處理請求的每一個步驟，可以記錄或估計(jì)用于處理請求的并發(fā)度。
如果系統(tǒng)運(yùn)行穩(wěn)定，有穩(wěn)定的平均吞吐量和響應(yīng)時間，那就很容易估算等待隊(duì)列的長度，只需要將吞吐量和駐留時間相乘即可。這就是所謂的利特爾法則法則（Little's Law）。這個法則很簡單，監(jiān)控工具經(jīng)常用它來估算隊(duì)列長度，但它只對具有穩(wěn)定均值的系統(tǒng)有效。
根據(jù)利特爾法則，平均隊(duì)列長度 = 平均吞吐量 * 平均駐留時間。
為了更好地理解這個法則的原理，我們需要知道請求是如何到達(dá)服務(wù)器以及請求之間的間隔是怎樣的。如果我們通過循環(huán)進(jìn)行簡單的性能測試，請求之間的間隔是固定的，那么利特爾法則就無效，因?yàn)檫@樣出現(xiàn)的隊(duì)列很短，而且這樣的測試不真實(shí)。我們通常會進(jìn)行這樣的測試，以為很完美，但是在將服務(wù)部署到生產(chǎn)環(huán)境之后，眼睜睜地看著它越跑越慢，吞吐量越來越低。
這種速率固定的循環(huán)測試不會有隊(duì)列出現(xiàn)，它們只是在模擬傳送帶。
在真實(shí)的網(wǎng)絡(luò)世界中，用戶都是獨(dú)立的，他們發(fā)送自己的請求，不同用戶發(fā)送的請求之間的間隔是隨機(jī)的。所以，在測試時，我們需要使用可以生成具有隨機(jī)等待時間的請求的生成器。大多數(shù)系統(tǒng)會使用隨機(jī)分布，雖然比模擬傳送帶要好，但也是不對的。要模擬真實(shí)的網(wǎng)絡(luò)流量，并讓利特爾法則生效，我們需要使用負(fù)指數(shù)分布（Negative Exponential Distribution）。Neil Cunther 博士在這篇文章中解釋了什么是負(fù)指數(shù)分布。
http://perfdynamics.blogspot.com/2012/05/load-testing-with-uniform-vs.html
要生成更加真實(shí)的隊(duì)列，需要使用恰當(dāng)?shù)碾S機(jī)時間算法。
但問題是，真實(shí)的網(wǎng)絡(luò)流量并不是隨機(jī)分布的，而是帶有爆發(fā)性質(zhì)的。想象一下，當(dāng)一個用戶打開一個手機(jī) App，它不會只發(fā)出一個請求，而是很多個。在網(wǎng)絡(luò)購物搶購活動中，會有很多用戶同時打開 App，這會導(dǎo)致流量爆發(fā)。這種分布形態(tài)叫作帕累托或雙曲線。另外，當(dāng)網(wǎng)絡(luò)經(jīng)過重新配置，流量會被延遲，就會出現(xiàn)隊(duì)列，而隊(duì)列會給下游系統(tǒng)帶來閃電式的沖擊。Jim Brady 和 Neil Gunther 寫了一些腳本，演示如何配置測試工具，從而獲得更加真實(shí)的流量。Jim Brady 還寫了一篇關(guān)于如何知道負(fù)載測試好壞的論文。
- https://github.com/DrQz/web-generator-toolkit
- https://arxiv.org/abs/1809.10663
相比常用測試工具默認(rèn)生成的流量負(fù)載，真實(shí)世界的流量負(fù)載更具爆發(fā)性，會導(dǎo)致更長的等待隊(duì)列和響應(yīng)時間。
等待隊(duì)列和響應(yīng)時間應(yīng)該是變化的，而且即使是在使用率很低的時候也會出現(xiàn)一些很慢的請求處理速度。那么，當(dāng)處理步驟中的某一步開始變慢時會怎樣？當(dāng)使用率增加，一些處理步驟沒有足夠的可用資源（比如網(wǎng)絡(luò)傳輸），那么請求相互爭奪資源的情況就會增加，駐留時間也會增加。一般來說，當(dāng)使用率達(dá)到 50% 到 70% 時，網(wǎng)絡(luò)就會逐漸變慢。
將網(wǎng)絡(luò)使用率保持在 50% 以下可用獲得更好的延時。
對于并行度高的 CPU，在使用率較高的情況下，速度會變得更慢，影響也更大，大到令你吃驚。如果你將最后一個可用的 CPU 看作爭用點(diǎn)，那么這就很直觀了。例如，如果有 16 個 vCPU，最后可用的 CPU 具有 6.25% 的處理能力，那么使用率就是 93.75%。對于具有 100 個 vCPU 的系統(tǒng)，它的使用率約為 99%。在穩(wěn)定狀態(tài)下，公式 R=S/(1-U^N) 可用來近似估算隨機(jī)到達(dá)服務(wù)器的請求的行為。
在多處理器系統(tǒng)中，隨著使用率的增加，平均駐留時間的膨脹會減少，但強(qiáng)度卻增加了。
使用率使用比例，而不是百分比，并將其作為處理器核數(shù)的冪底數(shù)。用 1 減掉使用率的 N 次冪，再用平均服務(wù)時間除以結(jié)果，就可以估算出平均駐留時間。如果使用率很低，平均駐留時間就會很接近平均服務(wù)時間。如果一個網(wǎng)絡(luò)的 N=1 并且使用率為 70%，那么用平均服務(wù)時間除以 0.3，得到的平均駐留時間就是低使用率時的三倍。
通常情況下，我們需要將平均駐留時間保持在 2 到 3 倍以下，這樣才能獲得更短的用戶響應(yīng)時間。
對于一個有 16 個 vCPU 并且使用率為 95% 的系統(tǒng)，0.95^16=0.44，再用平均服務(wù)時間除以 0.56，就會得到兩倍的平均駐留時間。如果使用率為 98%，那么 0.98^16=0.72，再用平均服務(wù)時間除以 0.28，平均駐留時間就會變慢，變得不可接受，而此時使用率僅增加了 3%。
當(dāng)多處理器系統(tǒng)的使用率很高時，一個很小的負(fù)載變化就會產(chǎn)生很大的影響，這是多處理器系統(tǒng)的一個問題。
Unix/Linux 系統(tǒng)有一個指標(biāo)叫作負(fù)載平均（Load Average），人們通常對它了解得不夠透徹，它存在一些問題。Unix 系統(tǒng)（包括 Solaris、AIX、HPUX）會記錄運(yùn)行中的和等待 CPU 的線程數(shù)，Linux 還會記錄等待 IO 阻塞的線程數(shù)，然后還使用了三種時間衰減值，分別是 1 分鐘、5 分鐘和 15 分鐘。首先我們需要知道的是，這個指標(biāo)可以追溯到 60 年代的單核 CPU 時代，所以我通常會將負(fù)載平均值除以 vCPU 的數(shù)量，從而得到具有可比性的值。其次，這個指標(biāo)與其他指標(biāo)不一樣，它沒有使用固定的時間間隔，所以它們不屬于同一種平均值。第三，這個指標(biāo)在 Linux 上的實(shí)現(xiàn)已經(jīng)成了一個 bug，被制度化成一個系統(tǒng)特性，其結(jié)果也被夸大了。
負(fù)載平均這個指標(biāo)不度量負(fù)載，也不是均值，所以最好把它忽略掉。
如果一個系統(tǒng)超載，請求達(dá)到的速度超過了處理能力，使用率就達(dá)到了 100%，那么上面的那個公式的除數(shù)就是 0，這樣會導(dǎo)致駐留時間無窮大。在實(shí)際當(dāng)中，這種情況會更加糟糕，因?yàn)楫?dāng)系統(tǒng)變慢時，上游的用戶會發(fā)送重試請求，這樣會加大系統(tǒng)的負(fù)載，出現(xiàn)“重試風(fēng)暴”。這個時候，系統(tǒng)就會出現(xiàn)很長的等待隊(duì)列，無法做出響應(yīng)。
當(dāng)系統(tǒng)使用率達(dá)到 100% 時就會出現(xiàn)很長的等待隊(duì)列，無法對請求做出響應(yīng)。
我發(fā)現(xiàn)系統(tǒng)的重試次數(shù)通常被配置得很大，超時被配置得很長，這樣會增加工作負(fù)載，更有可能出現(xiàn)重試風(fēng)暴。之前我有深入地探討過這個問題，后來又新寫了一篇文章。更好的做法是使用較短的超時時間和單次重試，如果有其他可用實(shí)例，最好把請求發(fā)給它們。
- https://www.slideshare.net/adriancockcroft/evolution-of-microservices-craft-conference/29
- https://dev.to/aws/if-at-first-you-don-t-get-an-answer-3e85
系統(tǒng)的重試時間不能全部設(shè)置成一樣，前端部分應(yīng)該設(shè)置得長一些，后端部分應(yīng)該設(shè)置得短一些。
一般情況下，人們會通過重啟來清楚超載的隊(duì)列，但一個經(jīng)過精心設(shè)計(jì)的系統(tǒng)會限制隊(duì)列的長度，并通過丟棄請求或做出“快速失敗”的響應(yīng)來削減流量。數(shù)據(jù)庫和其他具有固定連接數(shù)限制的服務(wù)都使用了這種方式。當(dāng)你無法獲得可用的請求能力就會得到一個快速失敗的響應(yīng)。如果連接數(shù)限制設(shè)置得太低，數(shù)據(jù)庫會拒絕它本該有能力處理的請求，如果設(shè)置得太高，數(shù)據(jù)庫在拒絕更多請求之前就已經(jīng)變慢了。
要多想想當(dāng)系統(tǒng)使用率達(dá)到 100% 時該怎么辦，以及如何設(shè)置恰當(dāng)?shù)南拗七B接數(shù)。
要想在極端情況下還能保持較好的響應(yīng)速度，最好的方式是使用快速失敗響應(yīng)和削減流量。真實(shí)世界中的大部分系統(tǒng)即使是在正常情況下也會出現(xiàn)很多慢響應(yīng)。不過，我們可以通過正確的指標(biāo)監(jiān)控來解決這些問題，對系統(tǒng)進(jìn)行精心的設(shè)計(jì)和測試，這樣就有可能構(gòu)建出具有最大化響應(yīng)速度的系統(tǒng)。
當(dāng)前標(biāo)題：為什么你的服務(wù)會變慢？
文章分享：http://fisionsoft.com.cn/article/djgccps.html
