06丨傾囊相授:我畢生所學的效能分析思路都在這裡了
效能分析思路和具體的實現之間,有一道鴻溝,那就是操作的能力。之前我為什麼聽不懂那些人的思路,其實是因為我沒有操作的功底。
而有了操作的功底之後,還有一個大的鴻溝要越過去,那就是從操作到對監控計數器的理解。這一步可以說讓很多效能測試人員都望而卻步了。
但是這還不算完,這一步邁過去之後,還有一個跳躍,就是相關性分析和證據鏈分析的過程。
如此一來,就會得到一張效能測試分析的能力階梯檢視,如下:
- 工具操作:包括壓力工具、監控工具、剖析工具、除錯工具。
- 數值理解:包括上面工具中所有輸出的資料。
- 趨勢分析、相關性分析、證據鏈分析:就是理解了工具產生的數值之後,還要把它們的邏輯關係想明白。這才是效能測試分析中最重要的一環。
- 最後才是調優:有了第3步之後,調優的方案策略就有很多種了,具體選擇取決於調優成本和產生的效果。
那麼怎麼把這些內容都融會貫通呢?下面我們就來說說效能測試分析的幾個重要環節。
應該說,從我十幾年的效能工作中,上面講的這些內容是我覺得最有價值的內容了。在今天的文章中,我們將對它做一次系統的說明。我先把效能分析思路大綱列在這裡:
- 瓶頸的精準判斷;
- 執行緒遞增的策略;
- 效能衰減的過程;
- 響應時間的拆分;
- 構建分析決策樹;
- 場景的比對。
瓶頸的精準判斷
TPS曲線
對效能瓶頸做出判斷是效能分析的第一步,有了問題才能分析調優。
之前有很多人在描述效能測試的過程中,說要找到效能測試中曲線上的“拐點”。我也有明確說過,大部分系統其實是沒有明確的拐點的。
舉例來說,TPS的檢視如下:
顯然,這是一個階梯式增加的場景,非常好。但是拐點在哪呢?有人說,顯然在1200TPS左右的時候。也有人說了,顯然是到1500TPS才是拐點呀。但是也有人說,這都已經能到2000TPS了,顯然2000TPS是拐點。
我們再來看一下這張圖對應的響應時間檢視:
是不是有人要說響應時間為4.5ms時是拐點了?
其實這些對拐點的判斷,都是不合理的。如果我們對TPS的增加控制得更為精準的話,那麼這個TPS的增加是有一個有清晰的弧度,而不是有一個非常清晰的拐點。
但是至少我們可以有一個非常明確的判斷,那就是瓶頸在第二個壓力階梯上已經出現了。因為響應時間增加了,TPS增加得卻沒有那麼多,到第三個階梯時,顯然增加的TPS更少了,響應時間也在不斷地增加,所以,效能瓶頸在加劇,越往後就越明顯。
那麼我們的判斷就是:
- 有瓶頸!
- 瓶頸和壓力有關。
- 壓力呈階梯,並且增長幅度在衰減。
如果你覺得上面的瓶頸還算清晰的話,那麼我們再來看一張圖:
在這個TPS的曲線中,你還能判斷出拐點在哪嗎?
顯然是判斷不出來拐點的,但是我們根據圖得出以下幾個結論:
- 有瓶頸!
- 瓶頸和壓力有關。
- 壓力也是階梯的,但是並沒有明確的拐點。
我們再來看一個TPS圖:
看到這張圖,是不是明顯感覺系統有瓶頸呢?那麼瓶頸是不是和壓力大小有關呢?
這種比較有規律的問題,顯然不是壓力大小的原因。為什麼呢?因為TPS週期性地出現降低,並且最大的TPS也都恢復到了差不多的水位上。所以,即使是壓力降低,也最多降低最大的TPS水位,會讓問題出現得更晚一點,但是不會不出現。
綜合以上,如果畫一個示意圖的話,TPS的衰減過程大概會如下所示:
- 隨著使用者數的增加,響應時間也在緩慢增加。
- TPS前期一直都有增加,但是增加的幅度在變緩,直到變平。
在這樣的趨勢圖中,我們是看不到明確的拐點的。但是我們能做的清晰的判斷就是:有瓶頸!
所以對TPS曲線來說,它可以明確告訴我們的就是:
- 有沒有瓶頸:其實準確說所有的系統都有效能瓶頸,只看我們在哪個量級在做效能測試了。
- 瓶頸和壓力有沒有關係:TPS隨著壓力的變化而變化,那就是有關係。不管壓力增不增加,TPS都會出現曲線趨勢問題,那就是無關。
這時你可能會問,為什麼不看響應時間就武斷地下此結論呢?其實響應時間是用來判斷業務有多快的,而TPS才是用來判斷容量有多大的。
響應時間的曲線
我們還是來看看響應時間,下面看一張響應時間圖:
它對應的執行緒圖是:
多明顯的問題,隨著執行緒的增多,響應時間也在增加,是吧。再來看它們對應的TPS圖:
到第40個執行緒時,TPS基本上達到上限,為2500左右。響應時間隨著執行緒數的增加而增加了,系統的瓶頸顯而易見地出現了。
但是,如果只讓你看TPS曲線,你是不是也會有同樣的判斷?那就是:有瓶頸!並且和壓力有關?所以說,其實TPS就可以告訴我們系統有沒有瓶頸了,而響應時間是用來判斷業務有多快的。
後面我們還會提到響應時間會是效能分析調優的重要分析物件。
執行緒遞增的策略
講完響應時間之後,我們再來看下執行緒遞增。
在見識了很多效能測試人員做的場景之後,必須得承認,有些場景的問題太多了。
首先,我們來看兩個場景的執行對比。
場景1的執行緒圖:
場景1的TPS圖:
場景1的響應時間圖:
場景2的執行緒圖:
場景2的TPS圖:
場景2的響應時間圖:
這兩個場景的比對如下:
有了這些對比資料之後,你是不是覺得哪裡似乎是有問題的?
對的!
TPS都是達到400,但兩個場景中執行緒遞增的策略不同,產生的響應時間完全不同。雖然都沒有報錯,但是第一種場景是完全不符合真實的業務場景的。這是為什麼呢?
在場景的執行過程中,首先,響應時間應該是從低到高的,而在場景1中不是這樣。其次,執行緒應該是遞增的,而場景1並沒有這樣做(這裡或許有人會想到秒殺的場景,認為場景1符合秒殺的業務設定,這個問題我們稍後提及)。最後,在兩個場景中,TPS的上限都達到了400TPS。但是你可以看到,在場景2中,只要40個執行緒即可達到,但場景1中居然用到了500執行緒,顯然壓力過大,所以響應時間才那麼長。
其實在生產環境中,像場景1這樣的情形是不會出現的。如果它出現了,那就是你作為效能測試的責任,因為你沒有給出生產環境中應該如何控制流量的引數配置說明。
同時,我們從上面的場景對比可以看到,對一個系統來說,如果僅在改變壓力策略(其他的條件比如環境、資料、軟硬體配置等都不變)的情況下,系統的最大TPS上限是固定的。
場景2使用了遞增的策略,在每個階梯遞增的過程中,出現了抖動,這就明顯是系統設定的不合理導致的。設定不合理,有兩種可能性:1. 資源的動態分配不合理,像後端執行緒池、記憶體、快取等等;2. 資料沒有預熱。
我們再回到之前說的秒殺場景。
說到秒殺場景,有人覺得用大執行緒併發是合理的,其實這屬於認識上的錯誤。因為即使執行緒數增加得再多,對已經達到TPS上限的系統來說,除了會增加響應時間之外,並無其他作用。所以我們描述系統的容量是用系統當前能處理的業務量(你用TPS也好,RPS也好,HPS也好,它們都是用來描述服務端的處理能力的),而不是壓力工具中的執行緒數。這一點,我在第5篇文章中已經做了詳細的解析,你可以回去再看看。
那麼,對於場景中執行緒(有些工具中叫虛擬使用者)遞增的策略,我們要做到以下幾點:
- 場景中的執行緒遞增一定是連續的,並且在遞增的過程中也是有梯度的。
- 場景中的執行緒遞增一定要和TPS的遞增有比例關係,而不是突然達到最上限。後面在場景的篇幅中我們會再說它們之間的比例關係。
- 上面兩點針對的是常規的效能場景。對於秒殺類的場景,我們前期一定是做好了系統預熱的工作的,在預熱之後,執行緒突增產生的壓力,也是在可處理範圍的。這時,我們可以設計執行緒突增的場景來看系統瞬間的處理能力。如果不能模擬出秒殺的陡增,就是不合理的場景。
這裡給出我做效能場景遞增的經驗值:
當然這裡也不會是放在哪個系統中都適合的遞增幅度,你還是要根據實際的測試過程來做相應的判斷。
有了這些判斷之後,相信大家都能做出合理的場景來了。
效能衰減的過程
有了瓶頸的判斷能力,也有了執行緒遞增的意識,那麼下面在場景執行中,我們就要有判斷效能衰減的能力了吧。
來,我們先看一個壓力過程中產生的結果圖。
在遞增的壓力過程中,隨著使用者數的增加。我們可以做幾次計算。
第一次計算,線上程達到24時,TPS為1810.6,也就是每執行緒每秒發出75.44個請求。
第二次計算,線上程達到72時,TPS為4375.1,也就是每執行緒每秒發出60.77個請求。
第三次計算,線上程達到137時,TPS為5034,也就是每執行緒每秒發出36.74個請求。
通過這三次計算,我們是不是可以看到,每執行緒每秒發出的請求數在變少,但是整體TPS是在增加的。
我們有很多做效能測試的人,基本上,只看TPS和響應時間的時候,在上面這個示例中,肯定會一直往上加使用者。雖然響應時間在增加,但是增加得也不多嘛。
但實際上,通過我們的計算可以知道,效能是在不斷地衰減的。我們來看一張統計圖:
通過紅線的大致比對可以知道,當每執行緒每秒的請求數降到55左右的時候,TPS就達到上限了,大概在5000左右,再接著往上增加執行緒已經沒有用了,響應時間開始往上增加了。
這就是效能衰減的過程(題外話,在上圖中,其實還有一個問題,就是在紅線前面,效能在上升的過程中有幾次抖動,這個抖動到後面變大了,也變頻繁了,如果這是必然出現的抖動,那也是配置問題,希望你注意到這一點)。
為什麼要這麼細緻地描述效能衰減的過程呢?
其實我就是想告訴你,只要每執行緒每秒的TPS開始變少,就意味著效能瓶頸已經出現了。但是瓶頸出現之後,並不是說伺服器的處理能力(這裡我們用TPS來描述)會下降,應該說TPS仍然會上升,在效能不斷衰減的過程中,TPS就會達到上限。
這也是前面我說的,效能瓶頸其實在最大TPS之前早就已經出現了。
那麼我們是不是應該在效能衰減到最大TPS時就停止場景呢?這個不一定的哦。
因為停不停場景,取決於我們的場景目標,如果我們只是為了得到最大TPS,那確實可以停止場景了。但是,如果我們要擴大化效能瓶頸,也就是說為了讓瓶頸更為明顯,就完全不需要停止場景,只要不報錯,就接著往上壓,一直壓到我們要說的下一個話題——響應時間變長,需要拆分。
響應時間的拆分
在效能分析中,響應時間的拆分通常是一個分析起點。因為在效能場景中,不管是什麼原因,只要系統達到了瓶頸,再接著增加壓力,肯定會導致響應時間的上升,直到超時為止。
在判斷了瓶頸之後,我們需要找到問題出現在什麼地方。在壓力工具上看到的響應時間,都是經過了後端的每一個系統的。
那麼,當響應時間變長,我們就要知道,它在哪個階段時間變長了。
我們看下這張圖。
這應該是最簡單的一個壓力測試邏輯了。一個應用,一個DB,結果也拆分出了8個時間段,這還是在我沒有加上壓力工具自己所消耗的時間的情況下。
如果我們要分析壓力工具中的響應時間,拆分的邏輯就是上面這個示意圖。
但是在真實的場景中,基本上不是這樣的。如果是內網,那基本上都是連在一個交換機上,所以通常是這樣的:
在這樣的拓撲中,我們仍然可以拆出來t1到t8的時間。只是實際動手的時候,思路一定要清晰,時間拆分是從哪裡到哪裡,要畫出來,不能混亂。
我們有很多手段可以進行時間的拆分,當然要看我們的應用支援哪一種。
如果我們是這樣的架構,拆分時間應該是比較清楚的。
首先我們需要檢視Nginx上的時間。日誌裡就可以通過配置$request_time $upstream_response_time得到日誌如下資訊:
14.131.17.129 - - [09/Dec/2019:08:08:09 +0000] "GET / HTTP/1.1" 200 25317 0.028 0.028
最後兩列中,前面是請求時間的28ms,後面是後端響應時間的28ms。
同時,我們再到Tomcat上去看時間。
172.18.0.1 - - [09/Dec/2019:08:08:09 +0000] "GET / HTTP/1.1" 200 25317 28 27 http-nio-8080-exec-1
請求時間消耗了28ms,響應時間消耗了27ms。
接著再來看一下前端的時間消耗。
從這裡可以看到,從發出請求到接收到第一個位元組,即TTFB是55.01ms,內容下載用了11.75ms。從這就可以看得出Nginx基本上沒消耗時間,因為它和Tomcat上的請求響應時間非常接近。
那麼網路上的消耗時間怎麼樣呢?我看到有很多人用TTFB來描述網路的時間。先來說明一下,TTFB中顯然包括了後端一系列處理和網路傳輸的時間。如下圖所示。
下面的紫色點是指要接收的內容。上面的紅色線就是TTFB。
如果接收完了呢?就是這個狀態。
所以,我覺得用TTFB描述網路的健康狀態並不合理。如果用Content Download來描述會更為合理。比如我們上面的這個例子中,那就是11.75ms下載了25317 Bytes的內容。
Tomcat上基本上是消耗了處理的所有時間,當然這中間也包括了MySQL花費的時間。而前端看到的其他時間就消耗在了網路中。
在這個例子中,主要說明了響應時間怎麼一步步拆。當然,如果你是下面這種情況的話,再一個個拆就比較辛苦了,需要換另一種方式。
你肯定想知道每個系統消耗了多長時間,那麼我們就需要鏈路監控工具來拆分時間了。比如像這樣來拆分:
從User開始,每個服務之間的呼叫時間,都需要看看時間消耗的監控。這就是時間拆分的一種方式。
其實不管我們用什麼樣的工具來監控,最終我們想得到的無非是每個環節消耗了多長時間。用日誌也好,用鏈路監控工具也好,甚至抓包都可以。
當我們拆分到了某個環節之後,就有了下一步的動作:構建分析決策樹。
構建分析決策樹
關於分析決策樹,我在很多場合也都有提及。
分析決策樹,對效能測試分析人員實在是太重要了,是效能分析中不可或缺的一環。它是對架構的梳理,是對系統的梳理,是對問題的梳理,是對查詢證據鏈過程的梳理,是對分析思路的梳理。它起的是縱觀全域性,高屋建瓴的指導作用。
效能做到了藝術的層級之後,分析決策樹就是提煉出來的,可以觸類旁通的方法論。
而我要在這裡跟你講的,就是這樣的方法論。
應該說,所有的技術行業在面對自己的問題時,都需要有分析決策樹。再廣而推之的話,所有的問題都要有分析決策樹來協助。
通過上面的幾個步驟,我們就會知道時間消耗在了哪個節點上。那麼之後呢?又當如何?
總要找到根本的原因才可以吧,我畫了如下的分析決策圖:
從壓力工具中,只需要知道TPS、響應時間和錯誤率三條曲線,就可以明確判斷瓶頸是否存在。再通過分段分層策略,結合監控平臺、日誌平臺,或者其他的實時分析平臺,知道架構中的哪個環節有問題,然後再根據更細化的架構圖一一拆解下去。
我在這裡,以資料庫分析和作業系統分析舉一下例子。
首先我們看一下資料庫分析決策樹。
比如針對RDBMS中的MySQL,我們就可以畫一個如下的決策樹:
由於這裡面的內容實在過多,無法一次性展現在這裡。我舉幾個具體的例子給你說明一下。
MySQL中的索引統計資訊有配置值,有狀態值。我們要根據具體的結果來判斷是否需要增加key_buffer_size值的大小。比如這種就無所謂了。
Buffer used 3.00k of 8.00M %Used: 0.04
從上面的資料可以看到,key buffer size就用到了4%,顯然不用增加。
再比如,我們看到這樣的資料:
__Tables_______________________
Open 2000 of 2000 %Cache: 100.00
Opened 15.99M 4.1/s
這就明顯有問題了。配置值為2000的Open Table Cache,已經被佔滿了。顯然這裡需要分析。但是,看到狀態值達到配置值並不意味著我們需要趕緊加大配置值,而是要分析是否合理,再做相應的處理。比如說上面這個,Table確實開啟得多,但是如果我們再對應看下這一條。
Slow 2 s 6.21M 1.6/s
你是不是覺得應該先去處理慢SQL的問題了?
關於資料庫的我們就不舉更多的例子了。在這裡只是為了告訴你,在分析決策樹的建立過程中,有非常多的相互依賴關係。
然後我們再來看一下作業系統分析決策樹,我在這裡需要強調一下,作業系統的分析決策樹,不可以繞過。
如果你想到作業系統架構圖就頭大,那麼這時候應該覺得有了希望。那就是我覺得作業系統上的問題判斷是比較清晰的,所以基於此決策樹,每個人都可以做到對作業系統中效能問題的證據鏈查詢。
但是!對嘛,總得有個但是。
對作業系統的理解是個必然的前提。我看過很多人寫的作業系統效能分析方面的書籍或資料,發現大部分人把描述計數器的數值當成效能分析。
怎麼理解這句話呢?比如說
“CPU使用率在TPS上升的過程中,從10%增加到95%,超過了預期值。” “記憶體使用率達到99%,所以是瓶頸點。” “I/O使用率達到100%。” 等等。
像這樣的描述,在我的效能團隊中,一定會被罵回去重寫。我要這些描述有什麼用?我要的是為什麼達到了這樣的值,原因在哪?怎麼解決?
就像分析決策樹中所描述的那樣,效能工程師要做的是一步步地細化分析,給出最終的原因。
有人說,如果按這個路子,似乎作業系統的分析並不複雜嘛。大概三五個命令就可以跳到程式碼層了。是的,對於操作來說,確實不多,但是對於判斷來說,那就複雜了。舉個例子來說明一下:
看到這樣的圖,你是不是有種手足無措的感覺?中斷能佔40%,sy CPU也能佔40%。這系統還用幹業務的事嗎?全乾自己的事去了,可見作業系統有問題!你是不是要做這個判斷了?
而實際情況是,這個主機上只有一個網絡卡佇列,而請求量又比較大。
所以要解決的是網絡卡佇列的問題,至於怎麼解決,那手段就多了。可以換個伺服器,可以多加幾個佇列,可以多接幾個節點…
以上只是給出幾個效能分析過程中常見的決策樹示例。在後續的分析過程例項中,我們將秉承著這種分析思路,一步步地走到瓶頸的面前。
場景的比對
為什麼要寫這一部分呢?因為我看到很多人對瓶頸的判斷,並不那麼精確,所以想寫一下場景比對的建議。
其實簡單來說,就一句話:當你覺得系統中哪個環節不行的時候, 又沒能力分析它,你可以直接做該環節的增加。
舉例來,我們現在有一個如下的架構:
可以得到這樣的結果:
從TPS曲線中,我們可以明顯看到系統是有瓶頸的,但是並不知道在哪裡。鑑於系統架構如此簡單,我們索性直接在某環節上加上一臺伺服器,變成這樣:
然後得到如下資料:
喲,沒好使!
怎麼辦?再接著加其他節點,我加了更多的JMeter機器。
再來看下結果:
真巧,TPS增加了!
看到了吧,這就是我說的場景比對。
當我們不知道系統中哪個環節存在效能瓶頸時,對架構並不複雜的系統來說,可以使用這樣的手段,來做替換法,以快速定位問題。
總結
在這一篇中,我說到了瓶頸的精準判斷、執行緒遞增的策略、效能衰減的過程、響應時間的拆分、構建分析決策樹以及場景的比對,這幾個環節,是效能分析過程中非常重要的環節。
從我的經驗上來說,這一篇文章可能是我工作十幾年的精華所在了。而這裡的每一個環節,又有非常多的細分,特別是構建分析決策樹這一塊,它需要太多的架構知識、系統知識、資料庫知識等等。鑑於本文只是想起到一個提綱挈領的作用,所以無法展開描述,希望在後續的篇幅中,我們儘量細緻拆解。
思考題
今天的內容雖然有點多,但總的來說,思路比較清晰,理解起來也比較容易。如果你認真學習了今天的內容,不妨思考兩個問題,為什麼執行緒遞增過程不能斷?構建分析決策樹的關鍵是什麼?
歡迎你在評論區寫下你的思考,我會和你一起交流,也歡迎把這篇文章分享給你的朋友或者同事,一起交流一下。
精選留言:
-
@zzw 2019-12-27 16:49:03
第一個問題:為什麼執行緒遞增過程不能斷?
這裡涉及開篇提到的效能分析能力 ——「趨勢分析」。
就像之前提到的一樣,分析效能資料趨勢需要對一個時間序列資料的分析,一般採用「線性迴歸分析」演算法。
迴歸分析研究的是多個變數之間的關係。它是一種預測性的建模技術,它研究的是因變數(目標)和自變數(預測器)之間的關係。這種技術通常用於預測分析,時間序列模型以及發現變數之間的因果關係。
假設有 N 個樣本點,這裡我們可以簡單理解線性迴歸演算法就是求一條直線 Y=f(X),使得各點到這個曲線的距離的絕對值之和最小。
在這種技術中,因變數(TPS)是連續的,自變數(執行緒數)可以是連續的也可以是離散的,迴歸線的性質是線性的。
但在效能測試中,由於系統本身的最大 TPS 上限是固定的,即服務端的處理能力(容量)是固定的,如果自變數(執行緒數)壓力過大,那麼系統平均處理時間(響應時間)會被拉長。不過這個時候其實瓶頸早就出現了。
所以在場景壓測中的自變數(執行緒數)遞增一定需要是連續的,並且在遞增的過程中要有梯度的,且場景中的執行緒遞增一定要和因變數(TPS) 的遞增有比例關係,且不是突然達到最上限,這樣才能準確找出系統的瓶頸點。
第二個問題:構建分析決策樹的關鍵是什麼?
決策樹基本上就是把我們以前的分析經驗總結出來,在做決策樹的時候,一般會經歷兩個階段:構造和剪枝。
概念簡單來說:
- 構造的過程就是選擇什麼屬性作為節點的過程構造的過程就是選擇什麼屬性作為節點的過程;
- 剪枝就是給決策樹瘦身,這一步想實現的目標就是,不需要太多的判斷,同樣可以得到不錯的結果。之所以這麼做,是為了防止“過擬合”現象的發生。
從效能分析角度來理解:
- 構造:需要根據經驗是對架構的梳理,是對系統的梳理,是對問題的梳理,是對查詢證據鏈過程的梳理,是對分析思路的梳理;
- 剪枝:需要對對不同時間序列效能資料的相關性分析,其核心就是要理解各個效能指標的關係,同時進行證據鏈查詢,根據資料的變化來推斷得出各種結論,比如故障判別、根因分析等。
[37贊]
-
小呀麼小二郎 2020-03-16 23:10:56
今天的內容有點多,寫了份總結,正好梳理一下思路
本節內容主要講了效能分析思路。從6個方面來分析:
首先,要準確的判斷瓶頸點。通過什麼來判斷呢?TPS曲線。TPS曲線能夠告訴我們系統是否有瓶頸,以及瓶頸是否與壓力有關。為什麼不需要響應時間曲線來判斷呢?因為響應時間主要是用來判斷業務快慢的。
其次,我們要確定我們設定的效能場景是正確的,執行緒是逐漸遞增的,而不應該一上來就上幾百個執行緒。原因:1、直接上幾百個執行緒不符合一般情況下的真實場景。2、即使是秒殺場景也有個“資料預熱”的過程(我的理解,資料預熱跟執行緒遞增應該差不多,有一個由小到大逐漸增加的過程)3、對於TPS已經到達上限的系統來說,除了響應時間的增加,沒有其他作用。
再次,我們要擁有能判斷效能衰減的能力。如何判斷?分段計算每執行緒每秒的TPS,如果這個數值開始變少,那麼效能瓶頸就出現了。此時再隨著執行緒的增加,效能逐漸衰減,TPS逐漸達到上限。
然後,我們知道效能開始衰減了,那麼是什麼原因導致的衰減?此時就需要對響應時間進行拆分,拆分的前提需要熟悉系統的架構,拆分的目的是要知道每個環節消耗的時間,拆分的方法可以通過日誌,可以通過監控工具,也可以通過抓包(抓包應該需要和日誌配合吧?以老師的例子來說,能抓到tomcat的請求和響應時間嗎?我感覺不能……)
再然後,最重要的地方到了,我們要逐步構建自己的分析決策樹。隨著效能分析經驗的累加,我們需要整理並總結每次遇到的效能問題以及相對應的解決方法,同時我們還要不斷擴充自己的知識庫:系統架構、作業系統、資料庫、快取、路由等等,並將這些知識與經驗結合起來。重新梳理,由大到小,由巨集觀到細節,去畫出自己的分析決策樹。
最後一點感覺是對第一條的補充,而且應該也是對小白(比如我)的一個提點,當我們剛開始進行效能分析,沒有思路的時候,那就可以通過這種替換法來幫助我們快速定位問題。當然,這種方法比較適合簡單的系統,如果系統很複雜,這樣替換不一定方便了。
這節課很重要,但是像我這種沒有實際分析調優經驗的小白來說,看懂跟理解好像還是缺少了實際操作在裡頭。這篇大概需要練習後再反覆的回看。
今天的思考題答案基本寫在上面的總結裡了,如果有理解不正確的地方請老師指正。最後,感謝老師把寶貴的經驗分享給我們,老師辛苦啦! [9贊]