现在基本上出行,一千五百公里内的路基本上我都选择坐高铁。

    每次坐高铁,只有一件事情可以做,就是写东西。

    写东西呢又全看心情,要是思路不断,可以一直有空闲的好几个小时,又没人打扰,那写东西,是嗖嗖的。

    感觉像个打字员一样,每秒平均120字没问题。再加上用五笔嘛又比较快,不会出现拼错的情况。像一些啐啐念的词,都是心里想到就打出来了。

    有时候回头看自己写的东西,感觉自己都没这么说过话。

    

    这会想聊一下性能分析中的曲线分析。

    我看过很多的性能报告,像这样的表格有很多。

(下面这个是平均响应时间的表格)

交易码

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

120

3

业务3

63

75

89

100

112

127

142

4

业务4

46

55

66

74

84

94

106

5

业务5

93

111

130

148

166

187

211

6

业务6

57

68

79

89

100

112

126

7

业务7

101

117

134

150

165

186

208

8

业务8

49

58

68

76

85

96

108

9

业务9

43

51

61

68

77

87

98

10

业务10

144

176

203

232

261

292

334

11

业务11

84

102

120

137

154

174

197

12

业务12

141

171

200

230

260

293

335

13

业务13

140

171

198

227

254

285

326

14

业务14

123

182

211

242

270

302

349

15

业务15

106

189

21

251

283

318

360

16

业务16

101

156

181

207

232

262

298

17

业务17

133

202

233

266

296

339

385

18

业务18

83

95

109

120

132

147

162

19

业务19

96

112

129

145

161

182

203

20

业务20

103

130

152

176

201

228

250

21

业务21

30

65

76

87

98

112

127


total

1849

2421

2619

3204

3592

4049

4581

然后画了一个TPS的图是这样:

性能分析之曲线分析_响应时间

    系统资源呢,也是像这样来个表格。

服务器

100

200

300

400

500

600

700

服务器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的图)。

性能分析之曲线分析_应用服务器_02

    看到这里,我觉得应该:

    有些人心里想,嗯,这图挺好,明明白白的。

    也有人心里想,嗯,我就是这么干的。

    也有人心里想,嗯,是呀就应该是这样呀,没毛病。

    也有人心里想,哦。


    我要说,不建议性能报告这么写。为啥呢?

    我们先来说说这样写的必要性。

    因为有些人做性能场景的时候,是把ramp up和ramp down这两部分的数据给截掉的。我之前问过别人为什么一定要抓稳定的TPS和响应时间曲线?为什么问这个问题呢?得到过一个回答:领导要看稳定的曲线;好汇报!

    为什么领导要看稳定的曲线,就要千方百计弄个稳定的、合领导心理的、稳定的曲线呢?(因为领导不高兴,就不给钱!那我只能说,没毛病!)这曲线是否反应真实的性能状态呢?

    还有一些人是因为看到别人这样写,所以他们也这样写,然而并没有什么反省。 

    那这样写有什么问题呢?

    嗯,其实没啥问题,我也就是问问。(不知道有没有人觉得很无奈看到这里?)

    

    下面正经一点写吧。

    我觉得这个曲线要是说反应TPS和系统资源的关系。这样说,似乎是没毛病的。所以经常看到下面的描述会是这样的:

    总TPS在达到4581的时候,服务器7的CPU使用率达到了92.25、服务器8的CPU使用率达到了89.92。

    上面这句也就是结果分析中的了。

    这样的结果分析有什么用呢?曲线中认真一点的就已经看出来了。为什么还要描述一遍图中的数据又称之为结果分析呢?

    我觉得这样的结果分析就是耍流氓。因为没有在分析,而只是在描述数据。做为广而告之的话,我觉得这样写也没什么不可以。但是做为结论分析的话,就不合理了。


    那说了半天,你觉得什么才是合理的结果分析的话呢?

    我觉得在描述TPS、RT、OS资源使用率等信息时,应该用实际的图。比如说:我们有一个java写的应用,为了便于引导思路,这里的结构图非常简单。

    就是: 压力工具 <-> 应用服务器 <-> DB服务器

    

    TPS图是这样的:

性能分析之曲线分析_性能分析_03

响应时间图是这样的:

性能分析之曲线分析_应用服务器_04

应用服务器 CPU图是这样的。

性能分析之曲线分析_数据_05

应用服务器 IO是这样的:

性能分析之曲线分析_性能分析_06

应用服务器 GC状态是这样的:

性能分析之曲线分析_应用服务器_07

应用服务器 网络是这样的:


性能分析之曲线分析_服务器_08


DB CPU是这样的(其他资源不帖了,我帖累了,默认其他的都没问题吧):

    

性能分析之曲线分析_性能分析_09

    

    上面的信息我觉得帖得够了。基本上有经验做性能分析的人,看到上面的图就知道一个明确的信息:这个系统有瓶颈。为什么?因为趋势!!

    所以,性能分析要趋势分析,要看的是很多数据组成的曲线。而不是每个梯度找个平均值来描述下值就是结果分析了。

    另外一个不能用均值描述的原因是,有很多测试,在资源的分配、增减的时候会出现响应时间和另外一些资源的毛刺。

    毛刺也是需要解释的。比如说我发的TPS图中就出现了00:10:00的时候,tps有下降的情况,并且后面还持续了一会。在这时候也看到了有响应时间的增加。

    为什么会出现这种情况呢?这个也是要在分析中解释的。在我这个图中是因为数据库主机中有其他的任务导致了这一段的sql执行时间普遍增加了几个毫秒。

    图中的曲线的解释是需要层层分析,慢慢细化,这个过程就是来描述上线后的情形。如果出现了某个用户的响应时间比较长,也是在意料之中的。


    结果分析是要描述单个曲线的同时,比如说,上图中的TPS是有按梯度增加的,也有没增加的,这就是场景的设计了。再结合响应时间图,有几个业务在随着TPS的增加而增加,增加的梯度和方差也都从结果中可以看到。 从TPS、RT上,可以把场景的设计明显的看出来。

    然后再从TPS、RT、资源图上,可以明显知道性能瓶颈是不是有的。但是这并不是说,瓶颈是可以从图上反应出来,那还是不行的。

    

    我现在在做项目中都会明确地说。如果硬件资源用不上去,那就先用硬件资源;硬件资源用上去了,目标没达到,那就开始调优。

    如果资源没用上去,TPS也不增加,响应时间又增加了,那必须得找到问题在哪。在性能结果分析中也要描述当前的状态是什么,合理不合理。

    还要描述性能瓶颈在什么地方。给出上线维护的建议。


    性能分析首先是全局趋势分析,然后层层细化的过程。

    如果只是为了报告的报告,那就另当别论了。


大家可以关注我们的公众号:7DGroup