|
|
知识路径： > 测试技术的分类 > 网络测试 > 网络应用测试 > 网络故障分析 >
|
|
相关知识点：6个
|
|
|
|
|
|
|
目前测试需要面对的大多数系统是复杂的分布式多层应用，这些应用的特点是：网络是应用中的一个组件，应用对网络产生影响，同时网络对应用也会产生影响，这样的特点造成应用在网络上的容量需求很难估计，失败的风险较大。如何针对分布式多层应用进行网络故障定位，以及在应用线程级分析中的应用是迫切需要解决的问题。网络应用分析可以发现多种问题，例如，客户端是否对数据库服务器运行了不必要的请求；当服务器从客户端接受了一个查询，应用服务器是否花费了不可接受的时间与数据库服务器通信等。借助于网络应用分析工具，可以在投产前调整应用在网络上的性能。
|
|
|
|
目前成熟的网络应用分析工具很少，并且从事网络故障分析的成本很高。为了实现分布式应用分析，规避应用实施风险，可以重点考虑以下几个方面的测试：
|
|
|
|
|
|
|
|
|
|
|
|
|
|
网络应用分析的关键因素包括：会话信息、包信息、响应时间信息、负载信息、高峰信息、线程信息等。同时还可以采用一些网络应用分析技术，例如，响应时间预测技术与带宽模拟技术等。
|
|
|
|
. 会话信息。指应用程序节点之间的会话信息，会话信息主要包括会话往返行程和会话流量信息。
|
|
|
|
①往返行程。一个往返行程是一对节点之间的一系列帧请求/回应。如下图所示的会话中，往返行程个数是2。一个应用程序如果具有较少的往返行程次数，那么它受网络品质的影响，例如网络延迟的影响较小，反之则较大。
|
|
|
|
|
|
|
|
②流量信息。会话的流量信息包括节点之间传输的字节数或者帧数目，如下图所示表示的是节点之间传输的字节数。
|
|
|
|
|
|
|
|
当捕捉到的节点很多，并且流量纷繁交织时，可以设定某种条件过滤流量。如下图一和如下图二所示，表示的是过滤前和过滤后的流量显示状态。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
可以先对包信息进行解码，然后分析包的详细信息，还可以分析包与包之间的关系、一个时间段内包的数量和包尺寸平均大小，以及包与线程的关系等。如下图所示为利用工具监控与应用相关的包大小及传输方向。大量的红色表示不充足的流量，传输线之间的间隔表示存在延迟问题。
|
|
|
|
|
|
|
|
|
|
如下图所示，分解出客户端响应时间、网络传输时间以及服务器（包括Web服务器、应用服务器、数据库服务器等）的处理时间，为分段定位故障提供依据。
|
|
|
|
|
|
|
|
|
|
如下图所示显示了有效负载与其他负载的比例，来评估与业务相关的流量效率。
|
|
|
|
|
|
|
|
|
|
需要明确高峰发生的时刻以及高峰期的流量，以确定广域网的容量需求，如下图所示表示了一个应用的平均流量和高峰流量。
|
|
|
|
|
|
|
|
|
|
可以对某个线程进行分析，也可对线程之间的关系进行分析。如下图所示，每个线程中都包含了一组包信息，所以可以分析线程和包之间的关联。线程也可以解析为协议信息进行分析。在线程分析时还可以将有关联的线程设置为线程组来分析。
|
|
|
|
|
|
可以利用工具为实验室中得到的测试数据进行响应时间预测。要完成这项工作需要定义三类参数，分别是带宽、背景负载（利用率）以及延迟，例如可以模拟在与服务器通信的带宽、负载、延迟参数下预测某个会话的响应时间。
|
|
|
|
|
|
|
|
如下图一、如下图二和如下图三所示，可以看出随着带宽的逐渐递增，数据传输时间以及网络通信时间的变化趋势。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
带宽模拟的目的是为系统传输选择一个合适的带宽，使得系统的峰值流量可以接受。这些测试数据为选择带宽提供了依据。
|
|
|
|
|
|
|
|
. 第一个例子命名为Taskl，访问一个网页，例如www.cnn.com，速度较慢，问题出在哪里？为了实现故障定位，需要关注的问题如下。
|
|
|
|
|
|
如下图所示，在初始的DNS请求之后有一个8秒的间隔，也就是服务器为了响应DNS请求花费了8秒钟时间。
|
|
|
|
|
|
|
|
如下图一和下图二所示，线程4、5、6所关联的数据包之间有10秒的时间间隔。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
这个应用涉及一个DNS服务器和一个Web服务器“www..CNN.com”。如下图所示为应用会话图。
|
|
|
|
|
|
|
|
|
|
从下图所示可知有效负载达到90.9%，应用流量效率较高。
|
|
|
|
|
|
|
|
|
|
从下图可以看到，25～30秒之间应用产生了持续流量高峰，可以将这个高峰与相关执行的线程关联起来。
|
|
|
|
|
|
|
|
. 第二个例子是一个对比测试，我们来看如下图所示的Task1与Task2的测试数据。
|
|
|
|
Task1的执行时间是3.43秒，Task2的执行时间是5.71秒。为什么Task2的流量小于Task1，而执行时间却长于Task1？是否存在性能问题？
|
|
|
|
|
|
|
|
首先我们发现在应用执行的开始存在一个1秒的时间间隔，在2～5秒之间有一个超过2秒的时间间隔。如下图所示为应用Bounce图。
|
|
|
|
|
|
|
|
|
|
客户端发出一个请求，Web服务器响应，在1秒之后又发出了同样的HTTP/GET请求，说明第一个请求失败。如下图所示为HTTP线程与Bounce关联图。
|
|
|
|
|
|
|
|
最后一个Oracle SQL请求在物理时刻1.65秒时发生，而下一个HTTP/GET请求直到物理时刻4.88秒时才发生，说明在请求之间存在较长时间间隔，服务器空闲。
|
|
|
|
从如下图所示的Oracle线程与Bounce关联图可知，每个时间间隔之后，系统都在等待客户端，可以初步将故障定位在客户端，下面可以进一步验证。
|
|
|
|
|
|
|
|
从下图可以看出，响应时间分析显示客户端响应时间为4.6秒，总的响应时间为5.7秒，客户端响应时间占总响应时间的80%左右，客户端的响应时间较长。下面从线程代码级再做进一步验证。
|
|
|
|
|
|
|
|
从下图所示的线程分析可以看到，发生延迟的HTTP请求都发生在客户端。
|
|
|
|
|
|
|
