文章翻譯
原文連結FlameScope是一個新的開源性能可視化工具，它使用次秒級偏移熱圖和火焰圖來分析周期活動、方差、擾動。我們在Netflix TechBlog上面，發表了技術文章
Netflix FlameScope，以及
工具的源代碼。
火焰圖很好了解，次秒級偏移熱圖了解起來要困難些（我最近發明的它）。FlameScope可以該幫助你了解後者。
總而言之，次秒級偏移熱圖是這樣的：x軸是一整秒，y軸是這一秒裡的幾分之一秒。這每個幾分之一秒都被稱作一個桶（或者說盒），表示這幾分之一秒裡，事件數量的聚合。盒子顔色深度表示發生的次數，顔色越深表示次數越多。
下圖一個真實的CPU上的次秒級偏移熱圖樣本:
這張圖中能分析出什麼資訊來呢？為了能把各種不同模式區分開來展示，我在這篇文章裡先畫了一些人工合成的樣本。實際使用FlameScope工具時，可以選擇你的各個模式，還能生成火焰圖，顯示對應的代碼路徑（這裡我不展示火焰圖）。
周期活動
1 . 一個線程，每秒一次
線程在每秒鐘内的同樣的偏移裡醒來，做幾毫秒的工作，然後回到睡眠。
2 . 一個線程，兩次每秒
每500ms喚醒一次。既可能是兩個線程，也可能是一個線程500ms 喚醒一次。
3 . 兩個線程
看起來像兩個線程均1s喚醒一次
4 . 一個忙等待線程，每秒一次
這個線程做約20ms的工作，然後睡1s。這是一個常見的模式，導緻每秒鐘喚醒抵消匍匐前進。
5 . 一個忙等待線程,兩次每秒
每500ms喚醒一次。有可能是單線程程式，每秒喚醒兩次。
6 . 一個計算較密集的忙等線程
斜率高，每秒做更多的工作，大約是80毫秒。
7 . 一個計算較不密集的忙等線程
斜率低，每秒做的工作較少，可能隻有幾毫秒。
8 . 一個忙等待線程，每5秒鐘喚醒一次
現在5秒喚醒一次。
我們可以根據夾角和喚醒的時間間隔，計算每個喚醒的CPU繁忙時間:
busy_time = (1000 ms / (熱圖行數 時間長度) tan(夾角)
例如45°夾角的線：
busy_time = (1000 ms / (501)) tan(45) = 20ms
方差
9 . cpu使用率100%
這是CPU完全被用滿的樣子
10 . cpu使用率50%
真實的工作負載更像是這樣，是由短請求、随機到達組成的。
11 . cpu使用率25%
相同的工作負載類型，大小在25%。
12 . cpu使用率5%
相同的工作負載類型，大小在5%。
13 . 負載增加
在2分鐘的尺度上，負載在變重。
14 . 變化的負荷
每30秒就有5秒的工作負載較重。
擾動
15 . CPU擾動
時不時地所有CPU都滿載個100ms。（比如垃圾回收）
16 . CPU阻塞
時不時地所有CPU都空載個100ms。（比如等I/O）
17 . 單線程阻塞
時不時地，隻有一個CPU沒有idle（表現為粉紅色長條，而不是白色長條）。（比如全局鎖）
最後這個模式很有趣：它發生在一個目前運作的線程持有一把鎖，而其它所有線程都阻塞在這把鎖上。
那麼該線程在做什麼呢？點選FlameScope的粉色線，就能看到此時的火焰圖。複雜的性能問題立刻變簡單。
總結
你能從這張圖中分析出什麼結論？
實際使用FlameScope工具時，可以選擇你的各個模式，還能生成火焰圖，顯示對應的代碼路徑。
我和同僚Martin Spier（也是該工具的主開發人員）11月8日在LinkedIn性能meetup上發表演講。
祝你使用FlameScope愉快，歡迎截圖分享你遇到有趣的模式!
Brendan
實踐
需要補充的是，作者最新的工作，将強大的Differential Flame Graph也內建到FlameScope中了，現在互動式地在FlameScope上，選擇兩個測試集以及對應的時間段，對比兩個測試組的事件采樣。
我在使用FlameScope時，發現并fix了FlameScope的若幹bug。也包括Differential Flame Graph跑不起來的一些bug。之後我便用它來進行了一些性能問題的複現。還發現其中一些有趣的模式。
首先，我想分析兩個測試組的排程特征。我對他們分别進行了perf sched record采樣，并使用FlameScope進行了資料可視化。
性能好的分組
用戶端

服務端
性能差的分組

我們發現性能差的分組，有大量的排程事件，而且發生地非常均勻。性能好的分組則是周期性地繁忙工作若幹毫秒（深紅色長條），我們還能發現背景裡有周期性的輕松任務（淺紅色長條）
這個對比，給了我們這兩個測試集的排程特征一個直覺的感受。但看來分析問題需要借助更多的資訊。
于是我使用了Differential Flame Graph分析兩個測試集的完整調用棧上的采樣。
該圖便給出一個重要線索，兩個測試集最重大的差別，在vfs_write->do_sync_write->sock_aio_write->inet_sendmsg->copy_user_enhanced_fast_string這條路徑上。（注意由于核心編譯優化等原因，調用路徑略有不準确）
性能好的測試組，多調用了很多次copy_user_enhanced_fast_string，性能差測試組的則很少。
之後的工作便于FlameScope關系不大了。這便是我使用FlameScope工具進行測試和性能調優的一個實踐。Bredan Gregg大神主導的這個軟體，對性能資料闡釋的直覺性真的太強了~