银行网络性能分析测试报告
合集下载
相关主题
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
银行网络性能分析测试报告
NPM/APM的方法论
2
端到端交易应用的完整性能监控 (NPM+APM)
客户端浏览器
广域网 TCP/IP 协议栈 IIS Native Pipeline .NET Worker Process
处理排队 起始 服务请求 网络、带宽、延迟、丢包 服务响应 网络、带宽、延迟、丢包 网页渲染时间 结束
JAVA/.Net应用）。
4
探针的工作原理
应用的KPI 汇总应用流的KPI指标 ，得到该应用的KPI； 并进行智能预警
早期预警
分析自上而下
故障预警，揭示潜在问题
数据自下而上
Flows
分析数据包里每个应用 流的KPI指标：包括流 量，网络传输时间，服 务器延时，重传…
故障定位
快速定位故障
Packets
网银检索到应用服务器响应时间高达10秒!
38
应用优化前后性能对比
39
高丢包率分析 - 个人应用
个人网银应用虚拟IP在3天内平均达到5%， 峰值到12%，需要进一步调查原因。
40
原始包察看
41
高丢包率分析 – 银企
网银银企、检索、数据库、应用集群都定时 连接以下3个地址
42
高丢包率分析 – 银企
每隔4分钟定时连接657端口，经了解657是 IBM HMC的管理端口，该行为疑似HMC代 理主动连接HMC，但连接和失败原因未知， 需要系统部进一步调查。
43
高丢包率分析 – FTP
时间都在凌晨2点左右，猜测是备份大量数 据导致，丢包会延误批处理完成的时间，建 议进一步检查丢包的位置。
44
高连接失败分析 – SSL服务器
通过3个web服务器的TCP连接数、 连接失败数、服务器响应时间和吞吐 可以清晰的看到,web_1和web_3的连 接数很平稳，而web_2一段 时间无 法被连接，直到15:40左右运维人员 意识该服务器上的防火墙服务配置错 误，关闭后恢复正常。 服务器响应时间比较平稳，但可以看 到夜间的固定时间会有突发，应该与 备份有关，希望可以优化。
45
从web_2到ssl_2的ICMP主机不可达通知
是否存在对单一IP地址TCP连 接数的限制？
46
Radware后流量统计
没有看到193.110.11.22服务器的流量，推测该服务器应该不可用，但很 多业务没有部署负载均衡，导致在应用不可用的时候，还在持续连接 web_2服务器。
47
Web服务器Radware后视图
13
仪表盘逐级下钻 - 响应时间分布图
14
连接异常的组和应用
15
16
全部流量统计 - 时序图
非常清晰的特征：夜间备份流 量尖峰，上午和下午是正常的 大流量，中午业务回落
17
全部流量统计 - 应用排名
负载均衡流量匹配
18
全部流量统计 - 会话对
非业务地址, 需要进一步了解该地址
19
20
Web应用慢页面统计
28
安装程序下载缓慢
最慢的页面时间高达1281秒,当我们打开瀑布图,看到该页面所有对象的加载过 程,发现是1个安装程序下载导致,但具体的原因还需要调查,是该用户的网速过 慢吗?
29
页面JS下载慢
30
页面图片下载慢
该图片花费160秒下载,没有优化,还是带宽过低,还是设备性能问题?
31
ATX进一步分析
通 过 镜 像 或 TA P 抓 取数据包，建立索 引并保存
获取故障 数据包证据
精细原始的证据
5
Riverbed 详尽的延时参数计算
服务器
Round Trip Time (Inbound) 连接建立时间
SYN SYN/ACK ACK REQUEST
客户端
服务器响应时间
DATA
Time
ACK
交互 1 Round Trip Time (Outbound) **
3
主要的技术手段
● NPM的主要技术手段
– 重点区域（如数据中心）监控，探针技术：通过抓取网络数据包进行 分析。 – 全网流量监控，Flow 技术： 采集网络设备统计的NetFlow, sFlow, J-Flow, NetStream
● APM的主要技术手段
– 端到端（用户端）监控，Web页面JavaScript脚本嵌入技术（针对Web 类应用）。 – 端到端（服务器端）监控， JVM/CLR Agent的代码植入技术（针对
9
网银定制应用仪表盘
网银助手响应时间超过阀 值，我们可以下钻查看web 性能分析视图
10
应用响应时间分布图
网银应用服务器的响应时间在 每天4点都增长的很高，这应 该和系统的批处理备份任务相 关，此时用户体验会非常慢， 建议优化。
11
按流量排名的组和应用
12
仪表盘逐级下钻 - SQLNET的会话对
21
页面族分析
22
页面族排名
23
用户会话跟踪
页面请求数量和页面时间 正相关
24
所有页面统计 - 自动排名
25
HTTP 404错误
26
HTTP 504错误 - 用户统计逻辑超时
该jsp运行60秒后，服务器返回504错误
27
HTTP200 - 业务逻辑缓慢
该jsp运行60秒后，服务器返回504错误
48
Web服务器Radware前视图
Radware提供的虚拟地址的TCP连接 数、连接失败数一直很平稳。 服务器响应时间在夜间的固定时间会 有突发，应该与备份有关，希望可以 优化。
EUE
网络 传输
Web服务器
性能 指标
代码 执行 网络 传输
代码执行
代码执行
局域网 TCP/IP Stack
网络、带宽、延迟
网络、带宽、延迟
App服务器
Apache WAS Thread Pool WAS JVM
处理排队 处理排队
性能 指标
代码 执行 网络 传输
代码执行
代码执行
远程调用 Web服务，数据库…
Fra Baidu bibliotek
数据传输时间
DATA ACK REQUEST
* 数据传输时间 = Payload 传输时 间 + 重传导致的延时 **Round Trip Time 的计算针对每个 DATA/ACK对。
6
DATA ACK
交互 2
7
网银定制业务组仪表盘
8
网银定制应用仪表盘
应用个人业务的虚拟地址 没有流量，怀疑是前端web 服务器没有指向负载均衡， 这与系统设计不符。
http是1个交互,但tcp是漫长的交互,而且 中间很多是没有应用负荷的包
32
ATX分析报告
162秒传输了1.5MB的数据,瓶颈主要在网 络传输
33
ATX分析报告
34
Wireshark查看原始包
连续的窗口冻结报文，验证了客户端的性 能是下载缓慢的瓶颈
35
36
连接失败排名
37
最慢服务器排名
NPM/APM的方法论
2
端到端交易应用的完整性能监控 (NPM+APM)
客户端浏览器
广域网 TCP/IP 协议栈 IIS Native Pipeline .NET Worker Process
处理排队 起始 服务请求 网络、带宽、延迟、丢包 服务响应 网络、带宽、延迟、丢包 网页渲染时间 结束
JAVA/.Net应用）。
4
探针的工作原理
应用的KPI 汇总应用流的KPI指标 ，得到该应用的KPI； 并进行智能预警
早期预警
分析自上而下
故障预警，揭示潜在问题
数据自下而上
Flows
分析数据包里每个应用 流的KPI指标：包括流 量，网络传输时间，服 务器延时，重传…
故障定位
快速定位故障
Packets
网银检索到应用服务器响应时间高达10秒!
38
应用优化前后性能对比
39
高丢包率分析 - 个人应用
个人网银应用虚拟IP在3天内平均达到5%， 峰值到12%，需要进一步调查原因。
40
原始包察看
41
高丢包率分析 – 银企
网银银企、检索、数据库、应用集群都定时 连接以下3个地址
42
高丢包率分析 – 银企
每隔4分钟定时连接657端口，经了解657是 IBM HMC的管理端口，该行为疑似HMC代 理主动连接HMC，但连接和失败原因未知， 需要系统部进一步调查。
43
高丢包率分析 – FTP
时间都在凌晨2点左右，猜测是备份大量数 据导致，丢包会延误批处理完成的时间，建 议进一步检查丢包的位置。
44
高连接失败分析 – SSL服务器
通过3个web服务器的TCP连接数、 连接失败数、服务器响应时间和吞吐 可以清晰的看到,web_1和web_3的连 接数很平稳，而web_2一段 时间无 法被连接，直到15:40左右运维人员 意识该服务器上的防火墙服务配置错 误，关闭后恢复正常。 服务器响应时间比较平稳，但可以看 到夜间的固定时间会有突发，应该与 备份有关，希望可以优化。
45
从web_2到ssl_2的ICMP主机不可达通知
是否存在对单一IP地址TCP连 接数的限制？
46
Radware后流量统计
没有看到193.110.11.22服务器的流量，推测该服务器应该不可用，但很 多业务没有部署负载均衡，导致在应用不可用的时候，还在持续连接 web_2服务器。
47
Web服务器Radware后视图
13
仪表盘逐级下钻 - 响应时间分布图
14
连接异常的组和应用
15
16
全部流量统计 - 时序图
非常清晰的特征：夜间备份流 量尖峰，上午和下午是正常的 大流量，中午业务回落
17
全部流量统计 - 应用排名
负载均衡流量匹配
18
全部流量统计 - 会话对
非业务地址, 需要进一步了解该地址
19
20
Web应用慢页面统计
28
安装程序下载缓慢
最慢的页面时间高达1281秒,当我们打开瀑布图,看到该页面所有对象的加载过 程,发现是1个安装程序下载导致,但具体的原因还需要调查,是该用户的网速过 慢吗?
29
页面JS下载慢
30
页面图片下载慢
该图片花费160秒下载,没有优化,还是带宽过低,还是设备性能问题?
31
ATX进一步分析
通 过 镜 像 或 TA P 抓 取数据包，建立索 引并保存
获取故障 数据包证据
精细原始的证据
5
Riverbed 详尽的延时参数计算
服务器
Round Trip Time (Inbound) 连接建立时间
SYN SYN/ACK ACK REQUEST
客户端
服务器响应时间
DATA
Time
ACK
交互 1 Round Trip Time (Outbound) **
3
主要的技术手段
● NPM的主要技术手段
– 重点区域（如数据中心）监控，探针技术：通过抓取网络数据包进行 分析。 – 全网流量监控，Flow 技术： 采集网络设备统计的NetFlow, sFlow, J-Flow, NetStream
● APM的主要技术手段
– 端到端（用户端）监控，Web页面JavaScript脚本嵌入技术（针对Web 类应用）。 – 端到端（服务器端）监控， JVM/CLR Agent的代码植入技术（针对
9
网银定制应用仪表盘
网银助手响应时间超过阀 值，我们可以下钻查看web 性能分析视图
10
应用响应时间分布图
网银应用服务器的响应时间在 每天4点都增长的很高，这应 该和系统的批处理备份任务相 关，此时用户体验会非常慢， 建议优化。
11
按流量排名的组和应用
12
仪表盘逐级下钻 - SQLNET的会话对
21
页面族分析
22
页面族排名
23
用户会话跟踪
页面请求数量和页面时间 正相关
24
所有页面统计 - 自动排名
25
HTTP 404错误
26
HTTP 504错误 - 用户统计逻辑超时
该jsp运行60秒后，服务器返回504错误
27
HTTP200 - 业务逻辑缓慢
该jsp运行60秒后，服务器返回504错误
48
Web服务器Radware前视图
Radware提供的虚拟地址的TCP连接 数、连接失败数一直很平稳。 服务器响应时间在夜间的固定时间会 有突发，应该与备份有关，希望可以 优化。
EUE
网络 传输
Web服务器
性能 指标
代码 执行 网络 传输
代码执行
代码执行
局域网 TCP/IP Stack
网络、带宽、延迟
网络、带宽、延迟
App服务器
Apache WAS Thread Pool WAS JVM
处理排队 处理排队
性能 指标
代码 执行 网络 传输
代码执行
代码执行
远程调用 Web服务，数据库…
Fra Baidu bibliotek
数据传输时间
DATA ACK REQUEST
* 数据传输时间 = Payload 传输时 间 + 重传导致的延时 **Round Trip Time 的计算针对每个 DATA/ACK对。
6
DATA ACK
交互 2
7
网银定制业务组仪表盘
8
网银定制应用仪表盘
应用个人业务的虚拟地址 没有流量，怀疑是前端web 服务器没有指向负载均衡， 这与系统设计不符。
http是1个交互,但tcp是漫长的交互,而且 中间很多是没有应用负荷的包
32
ATX分析报告
162秒传输了1.5MB的数据,瓶颈主要在网 络传输
33
ATX分析报告
34
Wireshark查看原始包
连续的窗口冻结报文，验证了客户端的性 能是下载缓慢的瓶颈
35
36
连接失败排名
37
最慢服务器排名