关于netscout clinet push 应用响应时间测量方法的讨论

孤独的意尹者 · 发表于 2010-8-18 11:00:59

在我们分析业务系统故障时，经常会涉及到应用响应时间的测量和分析，有很多网络分析产品都有对应用响应时间的统计测量，比如siniffer，netscout等，不同的产品对应用响应时间测量的方法应用有所差别，前段时间正好看到netscout关于应用响应时间测量的白皮书，里面提到了clinet pull与client push两种常见的基于TCP的应用响应时间测量方法，我在这篇文档中，针对netscout的client push的应用响应时间测量的方法提出了一些改进的建议，这个建议是拿来让大家讨论的，暂且不管这个改进建议在实际统计测量中的可行性，如果能够通过我的这篇文档，能够让大家对应用响应时间测量的方法有跟深入的认识，那么，我的目的就达到了。

徐徐渐进 · 发表于 2010-8-18 11:48:49

本帖最后由徐徐渐进于 2010-8-18 12:22 编辑

netscout对响应时间的测量好像有两种，即主动和被动，主动方式通过Cisco IP SLA实现，
被动方式则通过分析用分路器、镜像等方式抓取的数据包的Timestamp并结合TCP的原理进行分析实现的。

补充一个网上找到图:

孤独的意尹者 · 发表于 2010-8-18 11:55:36

2# 徐徐渐进

对，但是这里主要指应用响应时间的测量
IP SLA只能测试网络层的延时。

徐徐渐进 · 发表于 2010-8-18 12:56:38

呵呵，是的，不知楼主可否上传一下netscout的白皮书。

"从客户端带有PUSH 标志位的数据包开始计算，至服务器端响应应用层数据停止计算",个人认为，从理论上是可行的，但如果数据包在传输过程中遇到网络拥塞、重传等情况的话，这样计算就不准确了。

孤独的意尹者 · 发表于 2010-8-18 14:28:13

4# 徐徐渐进
\

上传netscout的文档

孤独的意尹者 · 发表于 2010-8-18 14:36:03

呵呵，是的，不知楼主可否上传一下netscout的白皮书。

"从客户端带有PUSH 标志位的数据包开始计算，至服务器端响应应用层数据停止计算",个人认为，从理论上是可行的，但如果数据包在传输过程中遇到网络拥塞、重传 ...
徐徐渐进发表于 2010-8-18 12:56

这个主要需要在靠近服务器端进行抓包分析，不能在网络中间进行。
在netscout的文档中有这样的描述：
In the recommended single probe scenario, in which the probe is located near the server, the application- specific response time is considered to be a server responsiveness metric, excluding network latency. In this case, total response time = server responsiveness + network latency.
翻译过来大致的意思是：
在单一探针部署的场景中，探针部署的位置位于服务器附近，此时的应用响应时间主要指服务器响应，不包括网络延时，在这种情况下，整体响应时间=服务器响应+网络延时

因此，在接近服务器端抓包，基本上可以忽略网络拥塞对测量的影响。
另外，如果是重传，这也是针对客户端的，如果在服务器端收到了客户端的push数据，应该会在tcp层面进行ACK，不管应用层是否有数据响应。只要服务器端在TCP层面进行ACK了，那么，客户端就不存在重传了。如果客户端的push数据在中间被丢弃导致的客户端重传，那么，这个情况对服务器端来说是完全不知道的，因此，也不存在客户端重传push数据对测量的影响。

long_323 · 发表于 2010-8-18 15:49:37

从客户端带有 PUSH 标志位的数据包开始计算，至服务器端响应应用层数据停
止计算。

有个疑问，有多少服务器会识别PUSH标志呢？

TCP/IP详解卷1第20章：
发送方使用该标志通知接收方将所收到的数据全部提交给接收进程。这里的数据包括与 P U S H一起传送的
数据以及接收方T C P已经为接收进程收到的其他数据。
在最初的T C P规范中，一般假定编程接口允许发送进程告诉它的 T C P何时设置P U S H标志。
例如，在一个交互程序中，当客户发送一个命令给服务器时，它设置 P U S H标志并停下来等待
服务器的响应（在习题 1 9 . 1中我们假定当发送1 2字节的请求时客户设置P U S H标志）。通过允
许客户应用程序通知其T C P设置P U S H标志，客户进程通知T C P在向服务器发送一个报文段时
不要因等待额外数据而使已提交数据在缓存中滞留。类似地，当服务器的 T C P接收到一个设
置了P U S H标志的报文段时，它需要立即将这些数据递交给服务器进程而不能等待判断是否还
会有额外的数据到达。
然而，目前大多数的 A P I没有向应用程序提供通知其 T C P设置P U S H标志的方法。的确，
许多实现程序认为P U S H标志已经过时，一个好的T C P实现能够自行决定何时设置这个标志。
如果待发送数据将清空发送缓存，则大多数的源于伯克利的实现能够自动设置 P U S H标志。
这意味着我们能够观察到每个应用程序写的数据均被设置了 P U S H标志，因为数据在写的时候就立即被发送。
代码中的注释表明该算法对那些只有在缓存被填满或收到一个P U S H标志时才向应
用程序提交数据的TCP实现有效。
使用插口A P I通知T C P设置正在接收数据的 P U S H标志或得到该数据是否被设置
PUSH标志的信息是不可能的。
由于源于伯克利的实现一般从不将接收到的数据推迟交付给应用程序，因此它们忽略所
接收的P U S H标志。

孤独的意尹者 · 发表于 2010-8-18 16:31:26

7# long_323 接收端对于PUSH标志位的识别主要是由TCP层来实现的，服务器在接受到来自客户端的带push标志位的数据后，TCP会立即将其跟缓存中存在的数据一起提交给应用进程处理。
服务器的TCP层能够做出这样的处理就行了，剩下的是应用进程的事情了。

long_323 · 发表于 2010-8-18 18:55:10

8# 孤独的意尹者
又仔细读了一遍，误会PUSH了，之前以为它不能被广泛的识别而没有多大意义，也没好好看。看书太快，得改呀！

徐徐渐进 · 发表于 2010-8-19 09:26:00

本帖最后由徐徐渐进于 2010-8-19 09:38 编辑

[quote]
这个主要需要在靠近服务器端进行抓包分析，不能在网络中间进行。
在netscout的文档中有这样的描述：
In the recommended single probe scenario, in which the probe is located near the server, the applicati ...
孤独的意尹者发表于 2010-8-18 14:36

[/q

呵呵，对的，不同的目的选择的捕包位置是不一样的；

再次证明选择正确的捕包位置在分析中是多么关键。

徐徐渐进 · 发表于 2010-8-19 09:34:59

另外，如果是重传，这也是针对客户端的，如果在服务器端收到了客户端的push数据，应该会在tcp层面进行ACK，不管应用层是否有数据响应。只要服务器端在TCP层面进行ACK了，那么，客户端就不存在重传了。如果客户端的push数据在中间被丢弃导致的客户端重传，那么，这个情况对服务器端来说是完全不知道的，因此，也不存在客户端重传push数据对测量的影响
孤独的意尹者发表于 2010-8-18 14:36

关于重传有个疑问：如果服务器端发送的ACK丢失，也会造成重传，这时我们应该怎样做呢？

孤独的意尹者 · 发表于 2010-8-19 11:34:44

关于重传有个疑问：如果服务器端发送的ACK丢失，也会造成重传，这时我们应该怎样做呢？
徐徐渐进发表于 2010-8-19 09:34

徐兄考虑的真细致啊！
在这种情况下，服务器端会再次受到来自客户端的请求数据，服务器端应该会再次发送响应的数据，那就再测量一次应用响应时间。至于其他的种种复杂的变数问题，我估计要在具体实现的时候多做实验看效果了，呵呵。

hgncwhj2008 · 发表于 2010-8-20 15:32:19

thank you for your sharing !!!!!!!!!!!!!!!!!!

rdhhh · 发表于 2010-9-23 08:46:36

努力学习中......

音乐最安全 · 发表于 2010-9-23 18:54:45

不错的分析，但文中有这么一处看了半天没看明白，麻烦孤独兄指点下，谢谢。
第8页（如下这么一句话）：
在这个交互的过程中，如果按照 netscout 的算法，可以计算出应用响应时间应该是T1、T2两个值，但是，实际中，T3才是真正的应用进程针对客户端上传数据的响应时间。

我看到此话的第一感觉是，按照netscout的算法，可读计算出应用响应时间应该不是T1,T2两个值，而正好就是T3这个值，因为按照第4页所示的服务器响应时间测量的量为：T4-T3的时间，也就是一个turn里面最后一个request和第一个response之间的间隔时间。

音乐最安全 · 发表于 2010-10-11 08:10:56

此话题不应当这样结束喔......................................

孤独的意尹者 · 发表于 2010-10-11 08:54:29

15# 音乐最安全 不好意思，这段时间比较忙，这个帖子沉下去，一直没留意你的发言，今天被顶上来才发现你的回复。
这个需要解释一下，你所说的第四页的算法是指“client pull”时的算法，我这里主要讨论的是“client push”时的算法。在我们发送post请求时，这个明显是一个clinet push的过程，在这个过程中，响应时间的计算就是按照client push的算法，如果按照client push的算法，那么就是在收到ACK时就计算响应时间。

zhangwb850 · 发表于 2010-12-25 17:57:20

Thanks for your sharing !

关于netscout clinet push 应用响应时间测量方法的讨论

本帖子中包含更多资源

评分

本帖子中包含更多资源

评分

本帖子中包含更多资源

评分

评分