案例-吉林移动网上营业厅分析.docxVIP

吉林移动网上营业厅分析问题描述根据用户反映吉林移动网上营业厅某些查询页面访问较为缓慢，如通话详单查询等。业务数据流向如上图所示，用户首先访问应用服务器发起请求，如果有需要调用接口查询数据的操作会发往前置机，由前置机向计费区调用接口查询数据。上图抓取点1采集用户访问应用服务器的全部通讯，抓取点2抓取前置机向计费区调用接口的全部数据，通过对抓取点1、2的数据采集分析“通话详单”查询缓慢的原因。数据分析我们模拟一次网上营业厅的查询操作，实时抓取全部通讯流量进行分析：抓取点1网络性能分析通过抓取多个TCP会话分析发现，每个TCP会话的三次握手时间差都很短，说明网络延时较小。建立连接后的数据传输同样延时较小，说明网络传输效率较高，服务器处理及客户端性能良好。不存在网络拥塞等网络问题。“余额查询”分析/service/fee/query.do?serviceType=19rnd=0.6238831533012996为本次测试的“余额查询”页面，我们定位到“余额查询”操作的TCP会话，如下图：通过下面的时序图可以清楚的看到，用户端发起“余额查询”请求之后，应用服务器在小于1ms内接收并确认了本次请求，在156ms之后对本次请求做出了数据回应，回应了17.551KB的数据。目前150多毫秒的延时不会造成用户端体验缓慢。但是在用户访问高峰时段，由于流量及请求量大大增加，访问延时可能会随之增大，极有可能造成用户在“余额查询”操作时体验缓慢。“通话详单查询”分析再来定位到访问时间较慢的“通话详单查询”：我们可以看到，用户端在发起service/fee/query.do“通话详单查询”请求之后，应用服务器在1ms内接收并确认了本次请求，在但在4秒钟之后才对本次请求做出了数据回应，回应了543KB的数据，响应时间明显比其他查询动作长。抓取点1小结通过对抓取点1的数据进行分析可以得出结论，用户端至应用服务器之间的网络传输效率较高，不存在网络拥塞延迟等情况。“通话详单查询”耗时较长主要是由于应用服务器收到请求后在几秒钟之后才对查询请求进行数据响应，这几秒钟的时间就造成了查询较慢的情况，具体是应用服务器与前置机之间的通讯较慢或是前置机调用计费区接口较慢需要从抓取点2进行分析。抓取点2网络性能分析通过抓取多个TCP会话分析发现，每个TCP会话的三次握手时间差都很短，说明网络延时较小。建立连接后的数据传输同样延时较小，说明网络传输效率较高，服务器处理及客户端性能良好。不存在网络拥塞等网络问题。“余额查询”分析我们定位到“余额查询”调用接口的TCP会话，如下图：通过下面的时序图可以清楚的看到，前置机在发起了“通话详单查询”请求之后，接口调用在1ms内接收并确认了本次请求，在170多ms之后对本次请求做出了数据回应，回应了800多B的数据。目前170多毫秒的延时不会造成用户端体验缓慢。但是在用户访问高峰时段，由于流量及请求量大大增加，访问延时可能会随之增大，极有可能造成用户在“余额查询”操作时体验缓慢。“通话详单查询”分析再来定位到访问时间较慢的“通话详单查询”：我们可以看到，前置机在发起了“通话详单查询”请求之后，接口调用在120ms左右接收并确认了本次请求，在但在4秒钟之后才对本次请求做出了数据回应，响应时间明显较长，并且与应用服务器返回的时间间隔相差不多，全部为4秒钟以上，说明应用服务器至前置机之间的延迟不大。造成“通话详单查询”较慢的主要原因为前置机向计费区调用接口发起请求，接口回应数据的时间较长造成。总结通过移动的相关网络拓扑结构图，本次希望看到3个关键节点的情况（9606、9603、计费），但是9603的镜像端口因为集团使用，无法接入分析，计费因为电口也被占满，只有光口，而我们本次带来的测试设备只有电口，所以也无法进行深入分析。根据现有资源，我们选取了9606的2条链路进行相关分析，大致查明原因，而且基本排除9603和9606的网络及设备问题。本次分析通过对抓取点1、2的数据进行分析，得知网络性能较好，传输效率很高，客户端及服务器性能良好，不存在网络拥塞等网络问题。通过对访问较慢的“通话详单查询”及“余额查询”操作进行精细分析时发现，前置机与应用服务器响应较快，不存在明显延迟情况。但前置机向计费区调用接口发起请求，接口回应数据的时间较长，并且在回应数据量较小“余额查询”时同样发现了接口回应数据较慢的情况。当业务查询处于高峰时段时，不排除“余额查询”操作时响应缓慢的情况。由于本次测试未能部署于计费区域，所以不能判断是由负载均衡设备还是由于其他原因造成数据响应缓慢。今后如果需要更为详细地探明计费区域究竟是哪个环节出现较长延时，只能在计费区域进行部署探测。