[心得] 使用 pyroscope adhoc 加速找到效能瓶頸

部落格: https://bit.ly/pyroscope-adhoc
Youtube: https://www.youtube.com/watch?v=3WfR46Q_9Kk

大家在開發軟體時，會快速迭代專案時程跟需求，功能越多，系統就會開始出現效能上的瓶頸，而最快的解決方式就是先垂直擴展，把 CPU 跟記憶體先往上加，但是這是治標不治本，所以之前有推薦大家一套如何在服務執行時，快速找到哪個地方執行較慢，請參考之前的文章『即時效能分析工具 Pyroscope』，Pyroscope 目前支援了很多語言，像是
Go, Python, Java, Ruby, Rust, PHP 及 .Net，如果你想要快速在本地端找到效能瓶頸，請繼續將本篇看完。底下會用 Go 語言實際範例教大家。

## 為什麼要用 adhoc profiling

Pyroscope 近期內推出 adhoc profiling 功能，大家想看看為什麼官方要推出此功能。原本 Pyroscope 推出此開源平台可以讓開發者在平台上線時，快速從時間點找到效能瓶頸的地方，但是移動到該時間點時，你會看到很多雜訊，而要持續檢測，開發者需要一直進行測試，而這方式無法在本地端快速驗證出來。

所以 Pyroscope 目標是推出 adhoc profiling 功能，讓開發者可以在本地透過
Pyroscope 快速驗證及找到效能瓶頸，而不用運行一整個服務，只要將特定的流程抓出來透過 Script 方式將效能數據產生出來，並且透過 Pyroscope CLI 直接讀取看數據。

(中間許多代碼，請直接上 Blog 文章)

## 線上 Profiling 服務

如果連本地端都不想安裝任何環境，可以透過底下兩個線上服務來完成。

* Upload and Share Interactive Flamegraphs[1]
* Playground[2]

可以將有效能問題的程式碼放到 Playground 上，並分享給團隊其他同仁，直接線上修改測試即可，其實跟 Go 提供的 Playground 差不多意思。

[1]: https://flamegraph.com/
[2]: https://playground.flamegraph.com/playground

## 心得

有了這個功能幫助挺大的，尤其是想在本機端做一些效能上分析，雖然有 pprof 可以使用，但是沒有好的 UI 介面，還是很難縮短除錯時間，而有了 adhoc 功能，還可以將數據分享給其他同事一起來幫忙。畢竟服務正式上線後，不會將 pyroscope 功能啟動，免得服務受到效能上的影響，而在測試站就會隨時監控，搭配 Prometheus + Grafana 找出特定時間點效能變化。

上面第一段有提到，目前支援多種不同語言，大家在本地端就可以快速測試不同寫法帶來不同的效能，而不是要將代碼推上機器後才可以驗證，真的縮短蠻多時間的。也可以在找到問題同時，先將 HTML 檔案附件在 Issue Tracking 系統上。

--