NimoLife

markdown # 關於RCA * RCA : 根本原因分析 ## 結論 * RCA是一種通用報告的格式，提供了一些通用的方法與計巧，讓問題可以從根本上被解決，可以參考[Here](https://asq.org/quality-resources/root-cause-analysis#resources) ## 我們小組上使用的簡易格式 * I. Problem Statement -> 定義/描述問題 * II. Cause & Effect -> 分析原因/造成影響 * III. Solution & Evaluation -> 提出解決方案/評估可行性 * IV. Topics behind the scenario -> 延伸討論 (如果還有的話) ### 節錄部份壓測的RCA報告 ```markdown ## I. Problem Statement * 接入平台需要能承受較大量的用戶。 * 壓測試後發現承載人數低下。 * 測試行為，登入 + 打訊息 + 圖片上傳 & 只打訊息，以不同的人數成增長與訊息數量測試。 ## II. Cause & Effect ### 登入導至OOM * 登入API 密碼加密每次使用64MB空間加密 -> 過多記憶體導至系統崩潰。 ### 併發下物件過多導至GC壓力 * 部份API在高併發下產生大量的物件建立與釋放 -> 使CPU 70%以上的時間花費在GC回收上 ### 編解碼使用的方式不適合高併發場景 * 通訊server的編解碼使用`map[string]interface` -> CPU效能 + GC壓力 ... ... ## III. Solution & Evaluation ### 登入導至OOM * 將密碼加密使用的空間降低 * 需注意玩家的token失效問題 * 要編寫過渡的程式才能無感更換 ### 併發下物件過多導至GC壓力 * 對於重覆使用的物件，在高併發下應使用sync.Pool池來減少GC壓力 ### 編解碼使用的方式不適合高併發場景 * 通訊server的CPU壓力可以透過多台機器分擔壓力(目前的做法) * 或調整編解碼方式減少物件壓力 * 由於MQ訊息沒分離，解決...

markdown # 非同步資料落地對於IM的重要性 ## 結論 今天我在將建立訊息的API，從先在MySQL落地，改由直接送給Client並另外起一個Cron做異步落資料落地之後，效能從`每秒20人送訊息200人收訊息(4000封/s)`提升至`每秒60人發訊息600人收(36000封/s)`，實屬相當大的進步。 ## 原因 我想是MySQL對於多次連接+小資料的更新與新增很不拿手，因為MySQL每次都是要碰Disk的，而且資料不是連續的導致I/O的時間會很長。 在調整成異步落地之後資料不會經過Disk，而是從API->MQ->Websockt->Client，所以快很多。 並且在異步的資料落地時，採用的是批次插入資料，這可以讓MySQL只需要少量I/O就可以完成大筆資料插入。 ## 應注意的部分 ### 不適合的場景 * 100%訊息都無法遺失，只要預到停電，OOM等事故，Mem是會消失的。 * 資料有立即提取的需求，既然是異步，就無法保證在加入一筆資料之後馬上查詢可以查到資料。 ## 適合的部份 * 資料不是那麼重要的，可以接收遺失，策略可以是幾分鐘內的可能會遺失，