使用 Splunk Real User Monitoring 最佳化行動應用程式啟動

作為 Splunk Mobile 部門的首席軟體工程師，我最具挑戰性和最有價值的工作之一，就是確保客戶體驗符合我們承諾的品質和標準。 

我和我的團隊是待命團隊的一員，致力於使用 Splunk Real User Monitoring (RUM) 和 Splunk On-Call (iOS 和 Android) App 來測量和最佳化關鍵服務等級指標 (SLI)。讓我們徹夜難眠的兩個 SLI 是「應用程式啟動時間」(App Startup Time) 和互動時間，後者也稱「就緒時間」(Time to Ready)。這些指標將衡量應用程式需要多久時間才能完全正常運作，並準備好與使用者互動。

為了追蹤結果和進度，我們建立了多個圖表和警報。只要 SLI 不符合我們的標準，就會向待命的工程師發出警示。 



 
當 “App Startup Time” 或 “Time To Ready” 的 p75 超過 5 秒時，系統就會呼叫我們的待命人員。收到通知時，我們會依照平台、應用程式版本和作業系統版本拆解 RUM 指標，以確定新程式碼是否影響了效能。此外，我們會在 “Session Details” 頁面中取得啟動時間或準備時間超出預期的應用程式執行個體的詳細資訊。每當我們收到通知，我們就會逐步改進 SLI，或是新增更多自訂事件以更深入地了解就緒序列的狀況。我們會召開事件後審查會議，討論每個警示以及為改進「應用程式啟動時間」和「就緒時間」而採取的行動。 

凌晨 3 點 16 分的呼叫
在我們和一個迄今最大的客戶之一簽約後不久，我們的待命工程師一周內在半夜被呼叫了兩次。在檢視 Splunk RUM 中的資料時，我們知道這個新客戶的 “o11y_fetch_and_store_dashboards” 時間非常長。 



 
在後台等待
在事件期間，我們發現抓取使用者偏好設定的 API 回應時間非常長 (5.8 秒)。儘管通常會在大型資料集中多次看到這一個 API 呼叫，但這裡只看到了一次，所以我們猜想這個大型資料集會被分頁。 

在將 Splunk RUM 追蹤連線回 Splunk APM 時，我們發現使用的主查詢並不是最佳的，並且沒有像我們預期的那樣對結果進行分頁。在對受影響的 API 安裝修正程式後，就緒時間就縮短了 10%。 

不斷迴圈
我們收集到的指標指向一段程式碼，它利用迴圈來對一個聯絡人列表擷取欄位。單是這個迴圈就佔了整個「就緒時間」的 50% 以上。事實證明，這個程式碼在聯絡人列表中迴圈了 3 次，為了擷取一個導致 “o11y_dashboard_list_favorite_load_time” 的關鍵字欄位。 

在我們的 QA 環境中，這一段未經最佳化的程式碼沒有被注意到，因為短的聯絡人列表變動很快；但對於這一個最大的客戶來說，執行速度非常慢，讓問題更加嚴重。透過最佳化程式碼 (僅在聯繫人列表中執行一次迴圈)，我們的後續版本為該大客戶縮短了最多 5 秒，將「就緒時間」效能提高了 33%，而且非工作時間的呼叫次數降到零。 



 
即時可觀察性 + 行動待命 = 更快樂的客戶
新版本發布後，新客戶的參與度提高了，這有助於我們長期留住他們。我們的待命作法提高了我們行動開發團隊內部的責任感，以時時監控我們的 SLI，並且將 Splunk RUM 新增到我們的行動可觀察性堆疊，藉此可以比以往更容易地改進它們。立即利用 iOS 和 Android 開始著手──註冊免費試用。
________________________________________
此部落格由 Splunk 資深產品經理 Seerut Sidhu 共同撰寫。
 
作者
Brian Gustafson
Brian Gustafson 是 Splunk 的首席軟體工程師。