建築釺

通過監控發現並修複熱點

通過馬特·希克斯1月16日

實時分割是Braze提供的每個產品的一部分。我們的客manbetx万博全站客户端戶希望信息隻在相關和及時的情況下發送給他們的用戶。但是，一旦你開發出一款產品並將其推向世界，客戶就會發現各種從未考慮過的使用方法。manbetx万博全站客户端構建易於監控和模塊化的係統可以讓您在發現這些用例時對它們做出反應。

我們用來監控的工具之一是New Relic。它為我們提供了數據庫正在使用多少資源的高級視圖，並允許我們深入到堆棧中的特定跟蹤。Braze從安裝在世界各地設備和網站上的SDK接收數據;這些數據通過後台作業處理器Sidekiq進行處理。在3月份，我們開始看到為一個特定客戶處理設備數據的主作業出現了問題。該作業更新用戶的Braze數據庫視圖，並檢查用戶是否采取了任何操作，從而觸發Braze向用戶發送推送通知、電子郵件或其他類型的消息。對於一個特定的客戶來說，這項工作所花費的時間的New Relic圖表是這樣的:

該客戶的作業處理時間在45天的時間內增加了4倍以上!為了保持處理時間的穩定，我們需要添加更多的工作服務器，這增加了我們的成本。另一幅圖給了我們一個可能發生什麼的提示:

從Memcached獲取數據的最慢響應時間增加了一倍。我們大量使用Memcached來減輕主數據存儲的負載，因此這是一個明智的探索路徑。因為Memcached是一個簡單的鍵值存儲，所以我們開始尋找其中存儲有大值的鍵。通過調試和跟蹤單個請求的代碼路徑，我們發現了與客戶使用Canvas產品相關的有問題的鍵。

帆布是一種向用戶發送帶有消息的引導旅程的方法。Canvas每月處理數十億條消息，可以支持數百個步驟的旅程。該平台使用事件驅動架構沿著路徑移動用戶。事件通過Braze SDK(和其他源)傳入，移動並可能向用戶發送消息。每個步驟都可以使用Braze的實時分割功能進行過濾。

當我們第一次構建Canvas時，我們假設所有應用在任何Canvas上的段都可以存儲在Memcached中的一個鍵上。對於導致性能問題的客戶來說，情況並非如此。他們有許多大型canvas，每個步驟都有不同的用戶細分標準。在Memcached中，所有這些條件都存儲在一個大的序列化對象中(一個帶有指向其條件的步長id的散列)。然而，給定用戶在Canvas中的位置，我們可以知道他們下一步可能會收到哪些步驟。從Memcached獲取關於所有可能步驟的信息最終是不必要的，並且會增加網絡流量和CPU負載。

為了解決這個問題，我們需要改變緩存結構和抓取策略。我們沒有在每個Canvas中使用一個鍵來包含所有可能的分割信息，而是考慮為每個步驟添加一個緩存鍵，僅包含其本身的信息。我們的代碼是模塊化的，可以直接進行更改。我們必須考慮的一件事是如何處理緩存缺失。

我們的第一個想法是獲取所有步驟信息並將其放入緩存中可以提高性能。這個想法是，如果某些步驟是需要的，畫布是活動的，所有的步驟可能很快就需要了。我們部署了這個變更，但是沒有看到我們想要的結果。緩存丟失的作業最終會花費太長時間來完成當時不需要的工作。我們做了最後一個調整，隻獲取丟失步驟的數據，我們的性能時間標準化到3月份之前的水平。