雲計算之路-阿里雲上：原來“黑色0.1秒”發生在socket讀取數據時
在昨天的博文（雲計算之路-阿里雲上：讀取緩存時的“黑色0.1秒”）中我們犯了一個很低級的錯誤——把13ms算成了130ms（感謝陳碩發現這個錯誤！），從而對問題的原因作出了錯誤的推斷，望大家諒解！ 從中我們吸取到了一個教訓：趁熱打鐵要小心，容易失去冷靜，作出錯誤的判斷。 今天我們痛定思痛，用了 ...
原文：雲計算之路-阿里雲上：讀取緩存時的“黑色0.1秒”
看到標題中的 . 秒 ，你也許會呲之以鼻：不會吧， . 秒也要計較，不是吃飽撐着，是沒吃飽也撐着。 依然沒撐着 在memcached應用場景中，響應速度是處於 ms級別的， . s可是比 ms慢了 倍啊。 如果你不相信 ms級別，請看這篇文章 微博CacheService架構淺析 中的一段話： 目前微博平台部分業務子系統的Cache服務已經遷移到了CacheService之上，它在實際的運行過程中 ...
2014-05-09 23:29 11 4864 推薦指數：
相關推薦
雲計算之路-阿里雲上：什么是“黑色1秒”？
為了更好地分享我們解決“黑色1秒”問題的過程，在這篇博文中我們將專門描述一下“黑色1秒”問題的表現。 “黑色1秒”是我們使用阿里雲以來繼“黑色10秒”之后遭遇的最奇特、最詭異、最難以捉摸、最富有戲劇性的問題。 它有2個最顯著的特征： 第一個是最直觀的表現，在Windows性能監視 ...
雲計算之路-阿里雲上：基於Xen的IO模型進一步分析“黑色0.1秒”問題
在發現雲服務器讀取OCS緩存的“黑色0.1秒”是發生在socket讀取數據時，而且是發生在讀取開始的字節，甚至在socket寫數據時（比如寫入緩存key）也會出現超過50ms的情況，我們的好奇心被激發到一個新的高度。 根據我們的實測，在雲服務器上創建一個新的TCP連接通常也不過3ms左右 ...
雲計算之路-阿里雲上：對“黑色30秒”問題的猜想
在雲上，底層的東西你無法觸及，遇到奇怪問題時只能靠猜想，所以使用雲計算會鍛煉你的想像力。 （上圖中藍色是ASP.NET的Requests Queued，另外一個是HTTP.SYS的Arrival Rate） 昨天我們發現了一個重要的線索——“黑色30秒”到來時，最初的表現是請求出現排隊 ...
雲計算之路-阿里雲上：“黑色30秒”走了，“黑色1秒”來了，真相也許大白了
雲上真是無奇不有，這兩天我們什么也沒動，“黑色30秒”招呼不打一聲就走了，而來了一位不速之客——“黑色1秒”；就寫了一篇博文，30秒就變成了1秒，看來多寫博客是硬道理。 在上篇博文的評論中有人說——就30秒，有必要這么較真嗎——當時想，別說30秒，哪怕1秒，我們也會較真。結果說1秒，1秒就來 ...
雲計算之路-阿里雲上：黑色1秒，微軟的問題還是阿里雲的問題？
“黑色1秒”問題經過一個多月的艱苦奮戰，今天終於取得了重要進展！我們終於有了足夠的數據證明不是微軟IIS的問題，就是阿里雲Xen虛擬機的問題。 這篇博文分享的是我們如何進行證明的，而且這次證明連Window性能監視器都不需要。 下面我們來分析一下今天10:37:35出現的“黑色1秒”（下面所用 ...
雲計算之路-阿里雲上：消滅“黑色n秒”第三招——禁用網卡的TCP/IP Offload
。而且阿里雲的雲服務器，所有的網絡負載都集中在一塊內網網卡上，SLB(負載均衡)用它，OCS(緩存服務)用它， ...
雲計算之路-阿里雲上：排查“黑色30秒”問題-為什么請求會排隊
針對Web服務器“黑色30秒”問題（詳見雲計算之路-阿里雲上：Web服務器遭遇奇怪的“黑色30秒”問題），經過分析，我們准備從這個地方下手——為什么會出現\ASP.NET\Request Queued大於0的情況（為什么請求會排隊）？ 首先， 通過Windows性能監視器去觀察，看能不能找到 ...