在昨天的博文(云计算之路-阿里云上:读取缓存时的“黑色0.1秒”)中我们犯了一个很低级的错误——把13ms算成了130ms(感谢陈硕发现这个错误!),从而对问题的原因作出了错误的推断,望大家谅解! 从中我们吸取到了一个教训:趁热打铁要小心,容易失去冷静,作出错误的判断。 今天我们痛定思痛,用了 ...
看到标题中的 . 秒 ,你也许会呲之以鼻:不会吧, . 秒也要计较,不是吃饱撑着,是没吃饱也撑着。 依然没撑着 在memcached应用场景中,响应速度是处于 ms级别的, . s可是比 ms慢了 倍啊。 如果你不相信 ms级别,请看这篇文章 微博CacheService架构浅析 中的一段话: 目前微博平台部分业务子系统的Cache服务已经迁移到了CacheService之上,它在实际的运行过程中 ...
2014-05-09 23:29 11 4864 推荐指数:
在昨天的博文(云计算之路-阿里云上:读取缓存时的“黑色0.1秒”)中我们犯了一个很低级的错误——把13ms算成了130ms(感谢陈硕发现这个错误!),从而对问题的原因作出了错误的推断,望大家谅解! 从中我们吸取到了一个教训:趁热打铁要小心,容易失去冷静,作出错误的判断。 今天我们痛定思痛,用了 ...
为了更好地分享我们解决“黑色1秒”问题的过程,在这篇博文中我们将专门描述一下“黑色1秒”问题的表现。 “黑色1秒”是我们使用阿里云以来继“黑色10秒”之后遭遇的最奇特、最诡异、最难以捉摸、最富有戏剧性的问题。 它有2个最显著的特征: 第一个是最直观的表现,在Windows性能监视 ...
在发现云服务器读取OCS缓存的“黑色0.1秒”是发生在socket读取数据时,而且是发生在读取开始的字节,甚至在socket写数据时(比如写入缓存key)也会出现超过50ms的情况,我们的好奇心被激发到一个新的高度。 根据我们的实测,在云服务器上创建一个新的TCP连接通常也不过3ms左右 ...
在云上,底层的东西你无法触及,遇到奇怪问题时只能靠猜想,所以使用云计算会锻炼你的想像力。 (上图中蓝色是ASP.NET的Requests Queued,另外一个是HTTP.SYS的Arrival Rate) 昨天我们发现了一个重要的线索——“黑色30秒”到来时,最初的表现是请求出现排队 ...
云上真是无奇不有,这两天我们什么也没动,“黑色30秒”招呼不打一声就走了,而来了一位不速之客——“黑色1秒”;就写了一篇博文,30秒就变成了1秒,看来多写博客是硬道理。 在上篇博文的评论中有人说——就30秒,有必要这么较真吗——当时想,别说30秒,哪怕1秒,我们也会较真。结果说1秒,1秒就来 ...
“黑色1秒”问题经过一个多月的艰苦奋战,今天终于取得了重要进展!我们终于有了足够的数据证明不是微软IIS的问题,就是阿里云Xen虚拟机的问题。 这篇博文分享的是我们如何进行证明的,而且这次证明连Window性能监视器都不需要。 下面我们来分析一下今天10:37:35出现的“黑色1秒”(下面所用 ...
。而且阿里云的云服务器,所有的网络负载都集中在一块内网网卡上,SLB(负载均衡)用它,OCS(缓存服务)用它, ...
针对Web服务器“黑色30秒”问题(详见云计算之路-阿里云上:Web服务器遭遇奇怪的“黑色30秒”问题),经过分析,我们准备从这个地方下手——为什么会出现\ASP.NET\Request Queued大于0的情况(为什么请求会排队)? 首先, 通过Windows性能监视器去观察,看能不能找到 ...