建築釺

通過監控發現和修複的熱點地區

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

實時分割釺提供的是每個產品的一部分。我們的客manbetx万博全站客户端戶想要的信息將用戶隻有當他們是相關的和及時的。但是一旦你建立一個產品,把它推向世界,顧客會發現各種各樣的從未想過的方式使用它。manbetx万博全站客户端構建便於監視和模塊化係統可以對這些用例發現。

我們用於監控的工具之一是新遺跡。它給了我們多少資源的高級視圖數據庫使用,並允許我們鑽深入具體的通過我們的堆棧跟蹤。釺接收數據從一個SDK安裝在設備和網站都在世界各地;這些數據被處理通過Sidekiq,後台工作的處理器。今年3月,我們開始看到問題的主要工作流程設備數據為一個特定的客戶。這個工作更新用戶的釺數據庫視圖並檢查他們采取任何行動,將引發釺發送推送通知,電子郵件,或其他類型的消息。New Relic圖的時間這個工作在一個特定的客戶看起來像這樣:

作業處理時間,該客戶已經超過4 x 45天時間!穩定處理時間,我們需要添加更多的工人服務器,我們的成本大幅提高。另一個圖給了我們一個提示可能發生什麼:

最慢的響應時間從Memcached獲得數據翻了一番。我們使用Memcached嚴重在加載了主要的數據存儲,所以這是一個明智的路徑探索。由於Memcached是一個簡單的鍵值存儲,我們開始尋找鑰匙,大值存儲在他們。通過調試和跟蹤單個請求的代碼路徑,我們找到了問題的關鍵與客戶使用我們的油畫產品。

帆布是一種發送用戶與信息引導的旅程。帆布處理數十億的消息一個月,可以支持旅行與數以百計的步驟。平台使用事件驅動架構沿著路徑移動用戶。事件來通過釺SDK(和其他來源),移動和可能消息的用戶。每一步可以使用釺的實時分割過濾功能。

當我們第一次建立畫布我們假設所有的地方隨時段應用帆布可以存儲在Memcached的一個關鍵。這個結果不是這樣為客戶誰是導致性能問題。他們有許多大的畫布,每個步驟都有一個稍微不同的用戶分類的標準。這些標準都是存儲在一個大型序列化對象(一個散列步驟id指向它的標準)在Memcached的一個關鍵。然而,給定一個用戶在一個畫布,我們可以知道他們可能接受下一個步驟。獲取所有可能的步驟從Memcached的信息最終被不必要的網絡流量和增加CPU負載引起的。

為了解決這個問題我們需要改變我們的緩存結構和抓取策略。而不是一個關鍵/帆布與所有可能的分割信息,我們認為添加緩存鍵的每一步隻包含信息本身。我們的代碼是模塊化的,足以讓這是一個簡單的改變。我們必須考慮的一件事是做什麼在一個緩存錯過。

我們的第一反應是,抓取所有步驟的信息,並把它在緩存中可以更好的性能。的想法是,如果需要的一些步驟,畫布是活躍的和可能需要的所有步驟。我們部署這種變化並沒有看到我們想要的結果。工作,有一個緩存錯過最終花了太長時間工作,不需要在那一瞬間。我們做了最後一次調整為失蹤的步驟,獲取數據和性能時間歸一化3月之前的水平。