現在基本上出行，一千五百公裡内的路基本上我都選擇坐高鐵。
每次坐高鐵，隻有一件事情可以做，就是寫東西。
寫東西呢又全看心情，要是思路不斷，可以一直有空閑的好幾個小時，又沒人打擾，那寫東西，是嗖嗖的。
感覺像個打字員一樣，每秒平均120字沒問題。再加上用五筆嘛又比較快，不會出現拼錯的情況。像一些啐啐念的詞，都是心裡想到就打出來了。
有時候回頭看自己寫的東西，感覺自己都沒這麼說過話。
這會想聊一下性能分析中的曲線分析。
我看過很多的性能報告，像這樣的表格有很多。
（下面這個是平均響應時間的表格）
<col>
交易碼
tps
100
200
300
400
500
600
700
1
業務1
61
73
85
96
107
120
136
2
業務2
52
62
74
83
94
106
3
業務3
63
75
89
112
127
142
4
業務4
46
55
66
84
5
業務5
93
111
130
148
166
187
211
6
業務6
57
68
79
126
7
業務7
101
117
134
150
165
186
208
8
業務8
49
58
76
108
9
業務9
43
51
77
87
98
10
業務10
144
176
203
232
261
292
334
11
業務11
102
137
154
174
197
12
業務12
141
171
230
260
293
335
13
業務13
140
198
227
254
285
326
14
業務14
123
182
242
270
302
349
15
業務15
189
21
251
283
318
360
16
業務16
156
181
207
262
298
17
業務17
133
202
233
266
296
339
385
18
業務18
95
109
132
147
162
19
業務19
129
145
161
20
業務20
103
152
201
228
250
業務21
30
65
total
1849
2421
2619
3204
3592
4049
4581
然後畫了一個tps的圖是這樣：
系統資源呢，也是像這樣來個表格。
伺服器
伺服器1
11.01
17.65
22.62
26.53
29.11
31.79
33.35
伺服器2
9.25
15.89
20.78
25.46
28.61
30.61
32.99
伺服器3
9.95
17.08
21.5
25.83
29.6
31.99
33.5
伺服器4
10.82
16.55
21.95
25.41
29.18
31.56
33.9
伺服器5
6.9
6.29
6.67
7.01
7.13
8.38
8.46
伺服器6
6.8
6.85
7.49
7.38
7.3
8.49
7.77
伺服器7
27.24
48
63.77
72.97
79.17
81.88
92.25
伺服器8
26.36
46.52
62.21
72.07
77.81
84.72
89.92
然後呢，再畫一個圖（假設這是cpu的圖）。
看到這裡，我覺得應該：
有些人心裡想，嗯，這圖挺好，明明白白的。
也有人心裡想，嗯，我就是這麼幹的。
也有人心裡想，嗯，是呀就應該是這樣呀，沒毛病。
也有人心裡想，哦。
我要說，不建議性能報告這麼寫。為啥呢？
我們先來說說這樣寫的必要性。
因為有些人做性能場景的時候，是把ramp up和ramp down這兩部分的資料給截掉的。我之前問過别人為什麼一定要抓穩定的tps和響應時間曲線？為什麼問這個問題呢？得到過一個回答：上司要看穩定的曲線；好彙報！
為什麼上司要看穩定的曲線，就要千方百計弄個穩定的、合上司心理的、穩定的曲線呢？（因為上司不高興，就不給錢！那我隻能說，沒毛病！）這曲線是否反應真實的性能狀态呢？
還有一些人是因為看到别人這樣寫，是以他們也這樣寫，然而并沒有什麼檢討。
那這樣寫有什麼問題呢？
嗯，其實沒啥問題，我也就是問問。（不知道有沒有人覺得很無奈看到這裡？）
下面正經一點寫吧。
我覺得這個曲線要是說反應tps和系統資源的關系。這樣說，似乎是沒毛病的。是以經常看到下面的描述會是這樣的：
總tps在達到4581的時候，伺服器7的cpu使用率達到了92.25、伺服器8的cpu使用率達到了89.92。
上面這句也就是結果分析中的了。
這樣的結果分析有什麼用呢？曲線中認真一點的就已經看出來了。為什麼還要描述一遍圖中的資料又稱之為結果分析呢？
我覺得這樣的結果分析就是耍流氓。因為沒有在分析，而隻是在描述資料。做為廣而告之的話，我覺得這樣寫也沒什麼不可以。但是做為結論分析的話，就不合理了。
那說了半天，你覺得什麼才是合理的結果分析的話呢？
我覺得在描述tps、rt、os資源使用率等資訊時，應該用實際的圖。比如說：我們有一個java寫的應用，為了便于引導思路，這裡的結構圖非常簡單。
就是： 壓力工具 <-> 應用伺服器 <-> db伺服器
tps圖是這樣的：
響應時間圖是這樣的：
應用伺服器 cpu圖是這樣的。
應用伺服器 io是這樣的：
應用伺服器 gc狀态是這樣的：
應用伺服器 網絡是這樣的：
db cpu是這樣的（其他資源不帖了，我帖累了，預設其他的都沒問題吧）：
上面的資訊我覺得帖得夠了。基本上有經驗做性能分析的人，看到上面的圖就知道一個明确的資訊：這個系統有瓶頸。為什麼？因為趨勢！！
是以，性能分析要趨勢分析，要看的是很多資料組成的曲線。而不是每個梯度找個平均值來描述下值就是結果分析了。
另外一個不能用均值描述的原因是，有很多測試，在資源的配置設定、增減的時候會出現響應時間和另外一些資源的毛刺。
毛刺也是需要解釋的。比如說我發的tps圖中就出現了00:10:00的時候，tps有下降的情況，并且後面還持續了一會。在這時候也看到了有響應時間的增加。
為什麼會出現這種情況呢？這個也是要在分析中解釋的。在我這個圖中是因為資料庫主機中有其他的任務導緻了這一段的sql執行時間普遍增加了幾個毫秒。
圖中的曲線的解釋是需要層層分析，慢慢細化，這個過程就是來描述上線後的情形。如果出現了某個使用者的響應時間比較長，也是在意料之中的。
結果分析是要描述單個曲線的同時，比如說，上圖中的tps是有按梯度增加的，也有沒增加的，這就是場景的設計了。再結合響應時間圖，有幾個業務在随着tps的增加而增加，增加的梯度和方差也都從結果中可以看到。 從tps、rt上，可以把場景的設計明顯的看出來。
然後再從tps、rt、資源圖上，可以明顯知道性能瓶頸是不是有的。但是這并不是說，瓶頸是可以從圖上反應出來，那還是不行的。
我現在在做項目中都會明确地說。如果硬體資源用不上去，那就先用硬體資源；硬體資源用上去了，目标沒達到，那就開始調優。
如果資源沒用上去，tps也不增加，響應時間又增加了，那必須得找到問題在哪。在性能結果分析中也要描述目前的狀态是什麼，合理不合理。
還要描述性能瓶頸在什麼地方。給出上線維護的建議。
性能分析首先是全局趨勢分析，然後層層細化的過程。
如果隻是為了報告的報告，那就另當别論了。
大家可以關注我們的公衆号：7dgroup