贵州移动WAP业务性能分析1218.docx
《贵州移动WAP业务性能分析1218.docx》由会员分享，可在线阅读，更多相关《贵州移动WAP业务性能分析1218.docx（29页珍藏版）》请在冰豆网上搜索。
贵州移动WAP业务性能分析1218
贵州移动WAP业务性能分析报告
北京西塔网络科技有限公司
版权所有XX
2006年12月
目录
贵州移动WAP业务性能分析报告1
1.概述3
2.WAP业务性能整体分析4
3.主要KPI值分析5
3.1.Radius认证连接时延分析5
3.2.Connect连接时延分析6
3.2.1.ConnectReply时延6
3.2.2.ConnectAck时延8
3.3.MobileType使用分析9
3.4.DNS性能分析11
3.4.1.DNS总体性能说明11
3.4.2.DNS解析失败分析11
4.WAP业务成功率分析14
4.1.Get成功率分析14
4.1.1.Get总体情况14
4.1.2.失败原因分析15
4.1.2.1.UserAbort错误15
4.1.2.2.WAPError错误18
4.1.2.3.ContentError错误21
4.2.Post成功率分析21
1.概述
WAP是一种无线应用协议，是一个全球性的开放协议。
WAP定义可通用的平台，把目前Internet网上HTML语言的信息转换成用WML描述的信息，显示在移动电话或者其他手持设备的显示屏上。
目前WAP业务已经成为中移动GPRS数据网络的核心业务之一，提供WAP网页浏览、图铃下载等服务。
WAP业务的性能也成为中移动评估GPRS网络性能的重要内容。
本次评估项目主要针对贵州移动GPRS网络的WAP业务性能，进行整体性能评估分析。
旨在评估局方现行GPRS核心网络的状况和WAP业务的性能，提供优化参考，帮助提高WAP业务的服务质量。
分析报告的样本为11月30日20:
00~22:
00之间两个小时的网络数据，采集接口为Gi、Gw接口，样本原始数据8G，使用西塔公司WAPMAX3.2软件分析。
数据采集示意图如下。
通过对贵州移动11月30日WAP数据业务的整体分析，认为局方的网络状况良好，多项KPI数值达到了中移动规定的健康值范围，整体成功率和时延情况良好。
不过值得注意的是，在某些KPI值上还有优化的潜能，WAP网关等几个重要网元设备也一定程度的存在问题，需要进行专题评估优化，以准确的掌握现行网络的健康状态和发现网络潜在安全隐患。
2.WAP业务性能整体分析
样本数据显示，在三段时间内，WAP业务的用户有一定的增加，Attempts数量的峰值出现在20:
00~21:
00时段。
WAP业务总体成功率为90.57%，各时段的成功率也比较平稳，均在平均值上下细小波动，但总体成功率仍低于中移动规定的健康值。
[Chart1]
Chart1WAPNumberGeneral
Date-Time
MaxCurrentGPRSUsers
MaxCurrentWAPUsers
TotalAttempts
SuccessRate（%）
GetSuccess（%）
PostSuccess（%）
11/3019:
00:
00
1,918
1,778
29,033
92.83
91.62
97.83
11/3020:
00:
00
2,339
2,135
305,500
91.16
89.8
97.07
11/3021:
00:
00
2,570
2,311
225,539
89.48
88.15
95.57
Average
90.57
89.23
96.52
WAP协议的使用中，WAP1.X协议的使用较为普遍，比例占到近七成，其成功率为88.2%，而WAP2.X协议的成功率略高，为93.12%。
[Figure1]页面的大小分布主要还是集中在0~10K这个范围。
[Figure2]
Figure1WAPProtocolUsagePercentage
Figure2PayloadDistribution
Page总体成功率不到70%，这是一个很低的数值。
在20:
00~22:
00间出现较大的下降，谷值出现在21:
00~22:
00之间。
[Chart2]较低的成功率的原因比较复杂，通过深入分析，可能与这些时段大量的Peer/UserRequest的中断有关，后面将做详细分析。
Java、Audio、Image、Text内容的业务访问成功率比较理想。
Video内容的业务访问成功率相比略微低一些，这可能与业务的开展和市场上手机能力有关。
[Chart3]
Chart2PageSuccessRate
Date-Time
PageNumbers
PageFailures
PageSuccess（%）
11/3019:
00:
00
3,573
694
80.58
11/3020:
00:
00
38,429
11,299
70.6
11/3021:
00:
00
32,731
12,043
63.21
Chart3PageNumberGeneral
Date-Time
Java
Audio
Image
Video
Text
Numbers
Success
Numbers
Success
Numbers
Success
Numbers
Success
Numbers
Success
11/30
1,210
93.22%
5,044
89.43%
157,989
94.59%
1,824
80.1%
254,076
93.91%
综合以上的分析，局方现有的GPRS数据网络中，WAP业务的总体情况良好，但是与中移动提出的健康值范围还有一点的差距，成功率上波动较大，许多地方存在优化的可能。
3.主要KPI值分析
3.1.Radius认证连接时延分析
样本中只有Gi、Gw接口数据，无法分析PDP激活情况，而Radius认证消息包含在Gi接口数据中。
样本数据中的Radius认证消息连接总体平均时延为1.14ms，且主要分布在0~10ms之间，且没有奇异值，连接情况较理想。
[Chart4]
Chart4RadiusConnectDelay
Date-Time
TotalNumber
Average（ms）
0-10（ms）
10-20（ms）
20-30（ms）
30-50（ms）
50-70（ms）
>=70（ms）
11/3019:
00:
00
2,731
1.16
2,728
2
0
1
0
0
11/3020:
00:
00
36,468
1.14
36,452
6
3
6
1
0
11/3021:
00:
00
28,965
1.14
28,955
5
1
4
0
0
3.2.Connect连接时延分析
3.2.1.ConnectReply时延
ConnectReply时延在Gi、Gw接口的平均时延分别为97.48ms和295.64ms，Gw接口的成功率较高，而Gi接口的成功率比较低，仅为77.97%。
[Chart5]
Chart5ConnectReplyInformation
Success
Average（ms）
0-5（ms）
5-10（ms）
10-20（ms）
20-50（ms）
50-100（ms）
100-200（ms）
200-500（ms）
>=500（ms）
Gi
77.97%
97.48
102,289
30,586
1,193
264
63
86
972
8,308
Gw
98.56%
295.64
34,444
15
1,713
62,882
238,476
117,883
17,903
32,042
那么究竟是什么原因导致Gi接口ConnectReply成功率这么低呢？
分析看到，在错误的统计中，使用WAP1.X协议的错误占到75%，而在这75%的错误中，253Acknotreceived错误又占到了92.79%。
[Chart6]
Chart6WAP1.XConnectReplyErrorPercentage
FailureType
WAPType
ErrorCode
Number
Rate（%）
ConnectReplyFailure
WAP1.X
253Acknotreceived
22,589
92.79
234Userrequest
942
3.87
225Sessiondisconnected
493
2.03
254ConnectReplynotreceived
119
0.49
008NoResponse
114
0.47
233Networkerror
47
0.19
002InvalidTID
27
0.11
240UserAbort
9
0.04
000Abort
5
0.02
在GGSN向WAPGW发送Connect请求后，WAPGW会响应ConnectReply，然后用户侧再发送ACK，这样连接建立。
253Acknotreceived错误就是WAPGW没有收到用户侧的响应，而使得连接失败。
ConnectReply的WTP层Trailer标示字段表明消息结束，需要回复ACK，但是客户侧没有发起ACK，而是在不到1s后继续发送连接请求。
[Figure3]
分析发现随着连接请求数的变化，连接的成功率也相应的变化。
[Figure4]图中标记处可以看到，当连接请求数激增时，连接成功率会降低（<80%）；而当连接请求数下降时，成功率又会回升（>80%）。
同时发现在20:
10左右变化较大，推断是否为当地WAP业务峰值起始时间。
需要说明的是Figure4中的TotalNumber为网关发出的Gi接口ConnectReply个数。
由于成功连接的样本中，这个数量和Gi接口ConnectRequest数量是一一对应的，所以可以通过这个数量的变化间接反映网络中连接请求数的变化。
Figure3ConnectReplyInformation
用户能在长时间内不断发出连接请求，说明上行信道没有问题，而网关能即时响应Reply，所以考虑是否下行信道出现问题，可能空口出现丢包或延时情况，导致用户没有接收到WAPGW的Reply，而导致连接失败。
此判断需进一步对多个接口进行监测才能确定。
分析中还发现，在WAP1.X协议的253Acknotreceived错误样例中，有21742个错误会话是由SonyEricssonT68这款手机产生的，并且比较集中在9个MSISDN号码上。
这款手机的大量失败连接严重影响了Connect成功率。
暂时无法确定Ack消息没有收到是否与这款手机有关，需要与手机制造商联系，但是可以判断，这款手机存在可以改进的地方。
这将在3.3节分析说明。
Figure4ConnectAckNotReceived
3.2.2.ConnectAck时延
Gw接口ConnectAck平均时延为1.67ms，集中分布在0~200ms之间。
而Gi接口ConnectAck平均时延为1004.96ms，1s以上时延的数量占到近20%。
按照其他省移动的经验，Gi接口的ConnectAck值低于1000ms比较理想，一些省份的ConnectAck平均时延能稳定在850ms左右，1000ms以下的时延所占比例超过80%。
影响这个时延的因素大致有两个：
一是空口的时延和丢包严重。
这将极大影响成功率和用户感知；
二是与手机型号有关，不同型号品牌的手机，能力值也不同。
[见3.3节]。
Chart7ConnectAckDelayDistribution
Average（ms）
0-200（ms）
200-500（ms）
500-1000（ms）
1000-2000（ms）
2000-3000（ms）
3000-5000（ms）
>=5000（ms）
Gi
1004.96
103
7,326
80,700
14,735
2,351
1,537
1260
Gw
1.67
503,038
1
2
1
5
9
1
Figure5ConnectAckDelayDistribution
同时，与ConnectReply数量变化对应的是ConnectAck消息的时延分布的变化。
[Figure5]可以清楚地看到在20:
10左右，用户侧回复的Ack时延也有一个大的跃迁，时延超过了1300ms，而此时ConnectReply的成功率有所下降。
[Figure4]这说明此段时间的网络状况不是很理想，空口出现了拥塞或丢包。
网络重要KPI的成功率对用户数量的变化过于敏感也侧面说明网络的健康值有待提高。
3.3.MobileType使用分析
样本中共有1247种终端类型，需要说明的是这个数值中包含了通过手机连接网络的方式，使用笔记本电脑上网的用户数。
详细情况可以参看MobileTypeTop100表单，里面列出了Page请求数排列前100个终端类型的相关KPI值。
正如前面所述，ConnectAckDelay与手机型号也有关系。
表单AckDelayTop200列出了样本中使用次数前200的手机型号及其Gi接口ConnectAck的时延大小。
3.2.1节提到，ConnectRelayFailure的67%失败连接会话（253Acknotreceived）使用的是SonyEricssonT68这款手机，并且比较集中在9个MSISDN号码上。
此款手机的用户有规律的向WAPGW发出连接请求，WAP网关均即时响应，但用户侧却没有ACK回复。
某些用户号码居然发起了1000次以上连接请求，这显然不是用户手动发出的。
[Figure6]
Figure6SonyEricssonT68AckNotReceived
分析还发现，用户在40分钟内（8:
05:
16PM739.042~8:
44:
54PM712.704）连续发送3293次连接请求，且均未向WAPGW回复ACK而失败。
而在此4秒之前，用户仍完成了一次成功的连接。
[Figure7]
产生这一情况的原因可能是此时网络出现拥塞，用户所在小区空口下行出现严重丢包。
ConnectReplyFailure中SonyEricssonT68手机用户大多数从20:
00点开始出现连接失败的，这与前面分析的连接成功率下降、业务峰值时间比较接近。
另外，较长时间内同一款手机大量次数的发出连接请求，且均没有Ack消息，这种频繁的毫无意义的连接请求严重消耗了网络资源，影响到网络服务质量。
怀疑此款手机存在不足，比如是否可以考虑设置连接请求的Timeout时间。
Figure7SonyEricssonT68ConnectRequest
3.4.DNS性能分析
3.4.1.DNS总体性能说明
局方有两个本地DNS服务器：
211.139.1.3、211.139.2.18。
被询问的频率较均匀，域名解析总体成功率为94.85%。
[Chart8]
两个服务器回复的平均时延分别为275.22ms（211.139.1.3）和216.39ms（211.139.2.18），时延分布较理想。
[Chart9]
Chart8DNSGeneralInformation
DNSServer
Numbers
Failure
SuccessRate（%）
UsageRate（%）
211.139.1.3
3,004
148
95.07
44.31
211.139.2.18
3,776
201
94.68
55.69
Total
6,780
349
94.85
Chart9DNSReplyDelayDistribution
DNSServer
Average（ms）
0-10（ms）
10-20（ms）
20-30（ms）
30-50（ms）
50-70（ms）
70-100（ms）
100-200（ms）
>=200（ms）
211.139.1.3
275.22
1,170
0
607
15
725
43
192
247
211.139.2.18
216.39
1,642
1
816
44
782
53
176
258
3.4.2.DNS解析失败分析
两个DNS服务器的失败解析错误种类分布中，003NoSuchName均占到很大的比重。
[Chart10]
而这种错误大多数都是用户填写错误或残损域名造成的。
[Figure8]
Chart10DNSErrorRate
ErrorCode
211.139.1.3
211.139.2.18
FailureNumbers
Rate（%）
FailureNumbers
Rate（%）
003Nosuchname
126
85.14
183
91.04
002Serverfailure
11
7.43
14
6.97
005Refused
6
4.05
0
0
255Therequesthasnoresponse
5
3.38
4
1.99
Figure8DNSNoSuchName
深入分析还发现，DNS服务器有时会出现查询无响应情况。
样本中，在20:
12:
09时刻211.139.2.18DNS服务器出现了一次无应答错误的出现。
但我们可以看到在此前后连续时间内均未出现这类情况。
[Figure9]
同时还发现这个域名的解析在几分钟前成功解析过，且生存时间为441s。
5分钟后（不到441s）解析请求应该能直接在缓存中得到。
这就可以排除陌生域名解析时间过长而未响应的可能。
[Figure10]
上述情况在样本中占一定的比例，在一定程度上说明DNS服务器可能存在性能不稳定的情况，需进一步跟踪确定。
Figure9DNSNoResponse_1
Figure10DNSNoResponse_2
4.WAP业务成功率分析
4.1.Get成功率分析
4.1.1.Get总体情况
样本中，Get总体成功率为89%，各时段的成功率比较均匀，没有较大的波动，说明WAP业务中，Get情况下的网络状况较理想。
[Chart11]
在失败的情况中，用户中断（UserAbort）引起的失败占到一半以上，这与其它省份的情况相似。
[Figure11]
Chart11GetGeneralInformation
Date-Time
GetNumbers
GetFailures
GetSuccess
UserAbort
WAPError
ContentError
11/3019:
00:
00
23,371
1,959
91.62%
1,163
602
194
11/3020:
00:
00
248,615
25,351
89.8%
13,310
7,804
4,237
11/3021:
00:
00
184,881
21,913
88.15%
10,991
6,449
4,473
Figure11GetSuccessRateandFailureDistribution
4.1.2.失败原因分析
4.1.2.1.UserAbort错误
UserAbort错误中232Peerrequest、234Userrequest、001ProtocolError三种错误占到了98.12%，其中232Peerrequest错误占到了近七成。
[Chart12]
Chart12UserAbortErrorPercentage
ErrorGroup
ErrorType
ErrorCode
Numbers
Rate（%）
UserAbort
WTPError
232Peerrequest
17,782
69.83
UserAbort
WTPError
234Userrequest
5,536
21.74
UserAbort
WTPError
001ProtocolError
1,668
6.55
UserAbort
WTPError
233Networkerror
145
0.57
UserAbort
WTPError
230Maximumreceiveunitsizeexceeded
94
0.37
UserAbort
WTPError
000UnknownWTPError
64
0.25
UserAbort
WTPError
225Sessiondisconnected
64
0.25
UserAbort
WTPError
008NoResponse
49
0.19
UserAbort
WTPError
007CapacityTemporarilyExceeded
31
0.12
UserAbort
WTPError
002InvalidTID
23
0.09
UserAbort
WTPError
240Unknown
7
0.03
UserAbort
WTPError
004NotImplementedSAR
1
0
232Peerrequest
Peerrequest的错误中有相当一部分是由于用户主动发起的中断请求。
在Gw接口的数据成功完整的下发到WAP网关，接着WAP网关将Get方式得到的数据下传给用户，用户能正常接收，可是没有接收完全就中断了。
其间没有重传、延时等现象出现，说明用户所处位置上下行信道传输情况良好。
所以判定此中断是由客户主动发起的。
[Figure12]
还有一种情况，WAP网关收到用户的Get请求，然后向内容服务器发起Get请求，可是并未得到回应，于是在70s后，用户侧断开中断连接。
此种情况的原因可能是内容服务器侧的问题导致用户侧无法继续等待而断开连接。
[Figure13]
Figure12UserAbortPeerReq_1
Figure13UserAbortPeerReq_2
234Userrequest
Userrequest错误和Peerrequest情况类似，还是以用户端主动提出中断请求为主。
根据其它省份的经验，上述两种错误情况还与WAP网关性能、内容服务器性能和上下行传输等因素有
升级会员 