性能分析之性能建模簡述

前言

建模的定義

業(yè)務(wù)模型和測試模型

監(jiān)控模型

分析模型

失效模型

排隊模型

總結(jié)

前言

建模的定義

業(yè)務(wù)模型和測試模型

監(jiān)控模型

分析模型

失效模型

排隊模型

總結(jié)

前言

經(jīng)常在性能領(lǐng)域里聽到建模這個詞，也看到有些人寫了一些文章或 PPT 描述建模。今天在網(wǎng)上也搜索了一下，看到有五花八門的內(nèi)容。我也寫一下我對性能建模的理解。

建模的定義

在一開始做性能項目的時候，就有些疑惑，到底什么是性能建模呢。搜索了下建模的定義：

建模就是建立模型，就是為了理解事物而對事物做出的一種抽象，是對事物的一種無歧義的書面描述。

建立系統(tǒng)模型的過程，又稱模型化。建模是研究系統(tǒng)的重要手段和前提。凡是用模型描述系統(tǒng)的因果關(guān)系或相互關(guān)系的過程都屬于建模。因描述的關(guān)系各異，所以實現(xiàn)這一過程的手段和方法也是多種多樣的。可以通過對系統(tǒng)本身運動規(guī)律的分析，根據(jù)事物的機理來建模;也可以通過對系統(tǒng)的實驗或統(tǒng)計數(shù)據(jù)的處理,并根據(jù)關(guān)于系統(tǒng)的已有的知識和經(jīng)驗來建模。還可以同時使用幾種方法。

大概有這么幾處地方涉及到了模型這個概念：

業(yè)務(wù)模型

測試模型

監(jiān)控模型

分析模型

失效模型

排隊模型

（如果有人看到有其他的性能模型的概念，也請告訴我一下）這些要怎么做呢？

業(yè)務(wù)模型和測試模型

基本上業(yè)務(wù)模型和測試模型的創(chuàng)建是來源于生產(chǎn)環(huán)境的數(shù)據(jù)統(tǒng)計。

如下圖所示：

做了這些業(yè)務(wù)的統(tǒng)計后，再把峰值（每小時或每分鐘或每秒）的業(yè)務(wù)提取出來，做成如下表：

其中交易的比例是根據(jù)實際的業(yè)務(wù)數(shù)據(jù)比例，過濾掉業(yè)務(wù)量太小不太可能出現(xiàn)大并發(fā)的業(yè)務(wù)之后，就有了測試比例。于是這個列表中就同時有了業(yè)務(wù)模型和測試模型。而這一操作過程就是建模的過程了。

這個過程如果被稱為建模也不是不可以，但是還是感覺像在打擦邊球的感覺，沒有那么讓人覺得很高大上。

監(jiān)控模型

監(jiān)控模型也是差不多的過程，它的依賴條件是部署架構(gòu)。所以要先畫出來有多少臺機器，每個機器上都安裝了什么，再看用什么工具去做監(jiān)控。這個抽象的分析過程我們也可以趨炎附勢地稱之為建模吧。

如下所示：

這里是我在之前一個項目中畫的簡圖（我把 Web Server 和 APP Server 畫到一起了），這里涉及到的機器大概有 150 臺。

這里要監(jiān)控的點有多少呢，我們可以來數(shù)一下：

150 個OS

2 個 LB

130 個web server

20 個 DB

4 個 MemCached

1 Network

177個監(jiān)控點 in total。

網(wǎng)絡(luò)之所以只寫一個是因為全用的是交換機，也就是這些機器都在同一網(wǎng)段里。如果是生產(chǎn)系統(tǒng)，可能還會涉及到多個網(wǎng)段，包括路由器、防火墻等內(nèi)容也是要監(jiān)控的。

這個是網(wǎng)絡(luò)部署的層面，如果有業(yè)務(wù)邏輯架構(gòu)圖的話，也可以根據(jù)業(yè)務(wù)邏輯架構(gòu)圖來畫。

這個過程，我們稱之為監(jiān)控建模。

分析模型

其實分析模型涉及到挺多內(nèi)容的，我們暫且來簡化一下。先說響應(yīng)時間的分段模型，如下圖所示：

這個圖想必有很多人看到過。這里基本上把響應(yīng)時間拆分到比較細的粒度了。根據(jù)這個圖做時間分段，可以明確地知道響應(yīng)時間到底在哪個環(huán)節(jié)消耗得多。

畫出這個圖的過程就是響應(yīng)時間分析建模的過程。

響應(yīng)時間分析模型中還有分層，這個比較難做，并且現(xiàn)在大部分人對從驅(qū)動層到上層的應(yīng)用層分析做不到那么細的粒度，更何況在大部分場景下也不是那么有必要。因為通過監(jiān)控工具就可以看出在哪個層面出問題了。

這里我畫個簡圖說明一下：

這個圖要表達的意思是，從數(shù)據(jù)進到一臺主機，從第一層開始，每一層都是可以拆分來分析的。如果出現(xiàn)一些比較極端的問題，比如說在第一層出現(xiàn)了問題，那么在第三層的監(jiān)控中就不太可能看得出來。但是通過上一圖的響應(yīng)時間分段分析，就可以確定是這個主機有問題。這種的分析要求技術(shù)功底就比較強了。

比如說運行一個 tomcat 服務(wù)器。要分析的層面就有：

O

S

層

?

J

V

M

層

?

T

o

m

c

a

t

層

?

業(yè)務(wù)代碼層

OS層-JVM層-Tomcat層-業(yè)務(wù)代碼層

OS層?JVM層?Tomcat層?業(yè)務(wù)代碼層

這樣劃分是不是夠細了呢？在一個具體的問題中，往往是不夠的。如下所說：

OS 層（拿 linux 舉例來說）：又要橫向和縱向細分。像 CPU、內(nèi)存、IO、File System、Process 等等，到這一層，有少數(shù)性能問題是可以通過改系統(tǒng)級的參數(shù)來解決問題的，也就是系統(tǒng)級的問題。那如果不是系統(tǒng)級的問題呢？就要接著看。

JVM 層：JVM 中又要分為堆和棧、class loader、execution engine 等，堆又要分為年輕代、年老代，持久代（sun jdk 1.8版本之后是metaspace元空間）。這些也是這個分析建模中要涉及的。 在這些之后呢。

Tomcat 層：應(yīng)用服務(wù)器的架構(gòu)相對來說比較簡單，像 tomcat，要理解的內(nèi)容就是 server、service、engine、host、context等，這些是 tomcat 架構(gòu)層的內(nèi)容。從監(jiān)控和配置的角度來看，要關(guān)注的內(nèi)容就是線程池、超時（超時又分為 connection timeout和 keepalive timeout）、隊列、緩沖區(qū)大小等內(nèi)容。這些分析了之后，能對 tomcat 層有個了解了。

業(yè)務(wù)代碼層：通常我們遇到的問題在這一層是最多的，所以也就有了很多人認為性能分析其實代碼功底是必須的，并且只要會了這一層的內(nèi)容，就非常專家了。因為其他的層面基本上是成熟的。可以理解這個想法，但是不能贊同只學(xué)習(xí)這一層的做法。因為性能問題確實就是會出現(xiàn)各個層面的問題。

像這種代碼層的問題，在我的經(jīng)驗中是最容易定位的。基本上做了profile之后都是可以快速定位的。所以在前面的文章中我有寫到剖析工具的內(nèi)容。這些剖析工具的使用比較簡單，不過要看懂?dāng)?shù)據(jù)，就得明白一些原理，不然看個堆棧都不知道是什么意思。

這些層面的抽象過程就是分析建模的過程。

所以基本上性能分析建模是分段和分層就可以了的，這個思路對大部分人來說是可以理解和接受的，但是難的是把這些內(nèi)容能融會貫通的解釋。

失效模型

在在性能領(lǐng)域里提失效模型的時候基本上都不是正經(jīng)的失效模型。因為做得太簡單。解釋得太表面。

失效模型是在以上的模型中模擬問題出現(xiàn)來分析影響的。它是有非常完整的數(shù)學(xué)理論來支撐的。這個過程不僅耗時費力，而且短時間內(nèi)很難把失效模型創(chuàng)建得特別完整。如果要做得粒度比較細的話，我覺得基本上在IT行業(yè)中是不現(xiàn)實的。

不過，我覺得有一種方式可以讓失效模型能很快用起來，就是宏觀分析。不像在分析模型中提到的那么細。而是把一臺主機、或一類主機、或一個網(wǎng)絡(luò)、或一個服務(wù)做為最細的粒度來做。

這個過程不費太多的時間，但是需要特別有經(jīng)驗的人來針對一個系統(tǒng)分析。這個建模的過程，也有完整的理論支撐。分析失效模型和影響分析是最重要的。

摘一個表格看一下：

這是一個 SOD 分級表，RPN 是風(fēng)險系數(shù)。

舉例來說，如果有兩個機房的服務(wù)器做分布式，如果基中一個機房停電了，對整個系統(tǒng)的影響是什么，流量的切換，壓力的承載都要詳細分析并通過測試，并且把相應(yīng)的解決措施寫出來。這個在很多企業(yè)都有做。并且這個一定要針對一個特定的系統(tǒng)做，只是理論的分析，沒什么價值。

排隊模型

排隊模型在性能分析中可以做宏觀分析手段，也可以做為微觀分析手段。小到一個磁盤的 IO 模型，大到一個完整的系統(tǒng)流量建模，都可以創(chuàng)建對應(yīng)的模型。

這就是最簡單的模型：M/M/1/∞ /∞ /FCFS。

這個在我之前的文章中已經(jīng)有比較多的描述了，請看這篇文章：性能分析之排隊論應(yīng)用

這就是另一個模型：M/M/C/∞ /∞ /FCFS。

我看到網(wǎng)上有人寫理發(fā)店模型的，其實那個還不能稱為模型，它只是排隊理論的一個小例子而已。

說到排隊論，這個數(shù)學(xué)理論非常完善，有興趣的可以看看相關(guān)的書。數(shù)學(xué)公式也是比較完整的。在《性能之巔洞悉系統(tǒng)、企業(yè)與云計算》那本書中有提到 /M/D/1 的模型的例子，是用來分析磁盤 IO 的。這個還不能算是架構(gòu)級分析的例子。

我前幾天用R語言做了一個 /M/M/C/FCFS 的模型實例，通過計算已經(jīng)以算出平均響應(yīng)時間和等待時間了。但是對一個具體的系統(tǒng)來說，這個模型仍然需要重建。因為一些輸入的變量是必須通過統(tǒng)計分析才能得到的，所以我還做了一些例子，并且用 SPSS 分析了到達鏈的分布。

總結(jié)

對性能建模的內(nèi)容寫了這么多，希望能讓做性能的人知道什么是真正的性能建模。

JVM Tomcat 云性能測試服務(wù) CPTS 應(yīng)用性能調(diào)優(yōu)

版權(quán)聲明：本文內(nèi)容由網(wǎng)絡(luò)用戶投稿，版權(quán)歸原作者所有，本站不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實的內(nèi)容，請聯(lián)系我們jiasou666@gmail.com 處理，核實后本網(wǎng)站將在24小時內(nèi)刪除侵權(quán)內(nèi)容。