云计算之路-阿里云上:超过70秒的请求抓包分析

超过70秒的请求是通过分析IIS日志发现的:

10.159.63.104是SLB的内网IP。

通过Wireshark抓包分析请求是9:22:21收到的(tcp.stream eq 23080):

09:22:21.299838000    10.159.63.104    10.161.241.208    HTTP    291    GET /eastsea/p/3764040.html HTTP/1.0 

这个请求响应内容的长度是:Content-Length 1154110(1.1MB)

云服务器(ECS)在收到请求后,发了一个ACK包:

09:22:21.354730000    10.161.241.208    10.159.63.104    TCP    66    http > 60895 [ACK] Seq=1 Ack=226 Win=66560 Len=0 TSval=16270579 TSecr=1049527471

接下来就是一堆的TCP segment of a reassembled PDU:

10.161.241.208    10.159.63.104    TCP    1514    [TCP segment of a reassembled PDU]

中间会出现一些错误:

1. TCP Dup ACK

10.159.63.104    10.161.241.208    TCP    78    [TCP Dup ACK 619713#1] 60895 > http [ACK] Seq=226 Ack=57921 Win=61440 Len=0 TSval=1049527542 TSecr=16270581 SLE=63713 SRE=75297

2. TCP Out-Of-Order

10.161.241.208    10.159.63.104    TCP    1514    [TCP Out-Of-Order] [TCP segment of a reassembled PDU]

3. TCP Fast Retransmission

10.161.241.208    10.159.63.104    TCP    1514    [TCP Fast Retransmission] [TCP segment of a reassembled PDU]

另外,中间也出现了大量的TCP Window Update:

10.159.63.104    10.161.241.208    TCP    66    [TCP Window Update] 60895 > http [ACK] Seq=226 Ack=175209 Win=16384 Len=0 TSval=1049528183 TSecr=16270632

最后在9:23:32才完成了响应内容的发送:

09:23:32.865387000    10.161.241.208    10.159.63.104    HTTP    486    HTTP/1.1 200 OK  (text/html)

Wireshark中记录的中整个发送耗时:

Time since request: 71.565549000 seconds

云计算之路-阿里云上:超过70秒的请求抓包分析,布布扣,bubuko.com

时间: 2024-10-12 18:15:52

云计算之路-阿里云上:超过70秒的请求抓包分析的相关文章

云计算之路-阿里云上:基于Xen的IO模型进一步分析“黑色0.1秒”问题

在发现云服务器读取OCS缓存的"黑色0.1秒"是发生在socket读取数据时,而且是发生在读取开始的字节,甚至在socket写数据时(比如写入缓存key)也会出现超过50ms的情况,我们的好奇心被激发到一个新的高度. 根据我们的实测,在云服务器上创建一个新的TCP连接通常也不过3ms左右.在黑色0.1秒期间,TCP包已经到达网卡,从网卡读到内存中竟然超过100ms,这太不可思议了!后来想想,如果.Net或Windows存在这样的问题,那微软就不是全球第一大软件公司,而是全球第一大忽悠公

云计算之路-阿里云上:读取缓存时的“黑色0.1秒”

看到标题中的"0.1秒",你也许会呲之以鼻:不会吧,0.1秒也要计较,不是吃饱撑着,是没吃饱也撑着. 依然没撑着!在memcached应用场景中,响应速度是处于1ms级别的,0.1s可是比1ms慢了100倍啊. 如果你不相信1ms级别,请看这篇文章(微博CacheService架构浅析)中的一段话: 目前微博平台部分业务子系统的Cache服务已经迁移到了CacheService之上,它在实际的运行过程中也取得了良好的性能表现,目前整个集群在线上每天支撑着超过300W的QPS,平均响应耗

云计算之路-阿里云上:因为网络问题,物理机换回虚拟机

今天早上7:00开始的从阿里云虚拟机到物理机的切换(详见切换至物理机验证“黑色1秒”是否与虚拟机有关),由于遭遇阿里云网络问题提前结束,14:38更改了DNS解析将流量切换回虚拟机. 网络问题是我们在14:30左右发现的,当时用浏览器打不开网站.用Firefox测试,显示连接超时. Ping发现很多丢包: 780 packets transmitted, 737 packets received, 5.5% packet loss round-trip min/avg/max/stddev =

云计算之路-阿里云上:原来“黑色0.1秒”发生在socket读取数据时

在昨天的博文(云计算之路-阿里云上:读取缓存时的"黑色0.1秒")中我们犯了一个很低级的错误--把13ms算成了130ms(感谢陈硕发现这个错误!),从而对问题的原因作出了错误的推断,望大家谅解! 从中我们吸取到了一个教训:趁热打铁要小心,容易失去冷静,作出错误的判断. 今天我们痛定思痛,用了一个下午的时间重新分析了"黑色0.1秒"问题,这次从EnyimMemcached的源代码下手(https://github.com/enyim/EnyimMemcached).

云计算之路-阿里云上:Wireshark抓包分析一个耗时20秒的请求

这篇博文分享的是我们针对一个耗时20秒的请求,用Wireshark进行抓包分析的过程. 请求的流程是这样的:客户端浏览器 -> SLB(负载均衡) -> ECS(云服务器) -> SLB -> 客户端浏览器. 下面是分析的过程: 1. 启动Wireshark,针对内网网卡进行抓包. 2. 在IIS日志中找出要分析的请求(借助Log Parser Studio) 通过c-ip(Client IP Address)可以获知SLB的内网IP,在分析Wireshar抓包时需要依据这个IP进

云计算之路-阿里云上:对“黑色n秒”问题的最终猜想——CPU C-states引起的

如果说2013年云计算之路的主题是"踩坑",那么2014年我们希望云计算之路的主题变成"填坑"--当然填坑是阿里云来完成的,我们只是见证曾经的坑坑洼洼变成平坦大道. 15号(周四)晚上我们发现了SLB会话保持的坑,16号晚上阿里云成功定位并进行修复,这两天正式发布后会填平这个坑.这次从踩坑到填坑的过程是最痛快的一次. 接下来我们的目标锁定在"黑色n秒"(刚发现一个英文说法:stuck for x seconds)这个坑我们最多.最神秘.最诡异的坑

云计算之路-阿里云上:CPU 100%引发的状况

今天下午17:00-17:05之间,在请求量没有明显变化的情况下,SLB中的1台云服务器的CPU突然串到100%(当时SLB中一共有3台云服务器),见下图: 造成的直接后果是请求执行时间变得超长,最长竟然达到了53秒(下图中的紫色线条). 另外伴随的表现是大量请求排队. 再看看这个时间段其它2台服务器的表现: 从这些现象分析,我们猜测CPU 100%这台云服务器出现了CPU资源争抢问题,将之从SLB中摘除后恢复正常. 云计算之路-阿里云上:CPU 100%引发的状况,布布扣,bubuko.com

云计算之路-阿里云上:什么是“黑色1秒”?

为了更好地分享我们解决"黑色1秒"问题的过程,在这篇博文中我们将专门描述一下"黑色1秒"问题的表现. "黑色1秒"是我们使用阿里云以来继"黑色10秒"之后遭遇的最奇特.最诡异.最难以捉摸.最富有戏剧性的问题. 它有2个最显著的特征: 第一个是最直观的表现,在Windows性能监视器(Performace Monitor)中会出现1秒的ASP.NET Applications -> Requests/Sec(简称QPS)为

云计算之路-阿里云上:消灭“黑色n秒”第一招——不让CPU空闲

昨天对"黑色n秒"问题的最终猜想以失败而告终,从而让我们结束了被动猜想阶段,进入了主动进攻阶段--出招. 今天出第一招--用C#写个小程序,让其在每个CPU核上运行一个线程,不让任何一个CPU核进入空闲(idle)状态,以进一步排除CPU idle引起的"黑色n秒". 在这一招中,借助的最重要的武器是System.Diagnostics.ProcessThread.ProcessorAffinity.通过给ProcessorAffinity设置一个掩码,就可以指定当