Plurk 訊息取得時間分布

這是一隻我寫的 Plurk 機器人(註一) 在不同時間差的情況下個別抓的「待回應訊息」 (註二) 分布狀況。

目前共有七隻 fetcher ,第一隻 fetcher 使用 Plurk Real Time Channel API ,其餘六隻 fetcher 使用 Plurk Polling API 並且以延遲 10s, 30s, 60s, 90s, 180s, 240s 的時間差 (offset) 來抓取訊息,圖表的縱軸代表「待回應的訊息」數目,橫軸則是時間差。整個圖表趨勢如果越往左靠,則表示 Plurk 系統對訊息同步的即時性越好,如果越往右靠,表示 Plurk 系統在訊息同步上花的時間越多。

之前在抓取訊息時,我都只抓取一分鐘之內訊息,過期的都不抓,但這樣也造成不少人說機器人沒有回應 (沒回應表示一分鐘內機器人沒抓到使用者發的訊息),以上圖來看,就是以前至少有 30% 的「待回應訊息」我漏抓了。

這種情況下,唯一的解決方法大概就是把時間差 (offset) 再加大。但其實這麼做的幫助很有限,因為使用者通常會因為等太久而自行砍掉沒有回應的訊息,然後機器人這邊則是會因此發生 (plurk not found) 的錯誤。

目前透過 Real Time Channel API 拿到的只佔 34% 左右,有 30% 是 offset 在 10s – 60s 之間拿到,而剩下 35% 則是超過 90s 才拿到。

備註:

  • 這隻機器人的架構設計分為 fetcher 和 replier ,可各別決定要跑幾個 process 起來,目前機器人有 26.8 萬個好友,現在實際狀況是跑七隻 fetcher 和一隻 replier 。
  • 「待回應的訊息」就是拿到的訊息中含有觸發機器人的關鍵字,其餘則為「不回應的訊息」 ,我會記錄每則回應的訊息,並以 fetch_offset 欄位代表是在哪個時間區間的 fetcher 抓到的,統計回應時間差的 SQL 如下

最近機器人的回應狀況不甚理想,我會再觀察一至兩週之後再 update 一下。

Posted in Programming

Leave a Reply

Your email address will not be published.