服務器資源:8核16G內存，6個機械磁盤，每個100G，用於mongo分片，10MB帶寬。
容量:用戶容量超過65438+萬，消息數1億。
性能評測:同時在線用戶65438+萬，每秒發送900條消息，消息延遲1秒(從發送方到接收方)。
啟動sdk模擬50個用戶的線上線下情況，消息可靠度為100%。
發送654.38+萬條消息，3條失敗，其他消息被對方準確接收並成功登陸本地db。對於三條失敗的消息，接收方沒有收到，系統消息壹致。
OpenIM是由前微信技術專家創建的開源即時通訊組件。Open-IM包括IM服務器和客戶端SDK，是壹個整體解決方案，開源代碼，壹切可控。
OpenIM可以支持所有平臺，目前支持Android、iOS、Flutter、Uni-app、react-native、JSSDK等。
OpenIM可用於企業內部辦公、交友、在線客服等項目，也可用於元宇宙。
Github地址:/#/
在單臺計算機的情況下，模擬在線用戶的消息發送過程。在線用戶數和消息數達到壹定數量級後，對系統的CPU、內存、磁盤占用率和消息延遲進行模擬。來確定用戶群達到壹定數量級後對服務器資源的預評估。該測試不是極限測試。首先，生產環境會受到用戶和消息數量的限制。第二，因為OpenIM的消息模型，消息壹開始會通過websocket發送給kafka。理論上，發送的消息的寫性能是兩者的結合，但真正的消息發送瓶頸其實是mongodb的隨機讀寫。
服務器資源:騰訊雲主機(香港)1套:linux Ubuntu 18.04.4系統，4核8G內存，單個機械硬盤。5Mb帶寬。
測試條件:移除消息存儲mysql(因為mysql只用於管理後臺，不影響在線用戶服務)。將日誌級別調整為4或更低。Kafka有2個分區和2個msg _ transfer。
測試流程:1客戶端(成都，window pc，4核16G內存)啟動10000個會話，模擬用戶與服務器建立長websocket連接，間隔隨機為50-100秒。兩個客戶端* * *模擬2萬個用戶同時在線，發送消息，觀察消息流各個模塊的處理能力，* * *統計2500萬條消息，觀察系統內存和磁盤資源的使用情況。
Mongodb數據情況
Redis數據狀況
磁盤狀態
資源占用分析
(1)redis占用內存很少，每個用戶壹條數據(包括token和seq)與用戶數量成正比，3萬個用戶占用幾十米內存。
(2)如果從2)mongodb中去掉緩存，內存消耗很小，每個文檔存儲5000條消息，與用戶數和消息數成正比，3萬用戶2500萬條消息索引只有950K(更好的查看mongo在緩存外消耗內存的方式)。
(3)2500萬條消息，占用磁盤空間10G。
(4)每秒有150條消息，cpu占用總量的50%，即2核。
技術性能分析
(1)性能的瓶頸在於mongodb寫操作。有1條消息，需要根據發送方和接收方拆分兩次，mongodb寫兩次，以後可以進壹步優化mongodb讀寫。
(2)對於cpu消耗高的模塊，未來做壹個整體優化。
(3)性能穩定，不會隨著數據量的增加而降低。機械盤iops達到200，基本達到設備極限。
服務器資源:8核16G內存，6個磁盤，每個100G，用於mongo分片，10MB帶寬。
性能評測:同時在線用戶65438+萬，每秒發送900條消息，消息延遲1秒(從發送方到接收方)。
(1)mongo集群部署，支持上億用戶同時在線，消息數千億；
(2)簡化集群部署；
(3)數據備份和恢復工具；
以上主要測試服務器的性能，但是壹個完整的IM解決方案不僅僅是服務器的工作。客戶端的重要性其實是毋庸置疑的，包括如何使用seq與服務器同步消息，如何在保證消息收發定時的情況下回調客戶端(會話變更、添加和新消息)，如何與本地db和seq同步消息，如何結合消息推送和拉取來保證消息收發的可靠性。
事實上，消息的可達性(可靠性)比性能測試更重要。所以在做性能測試的同時，也要測試消息的可達性(可靠性)。如果不能保證消息收發的正確性，再高的性能也是徒勞的。本文主要總結了OpenIM的消息可達性測試的方案、過程和結果。首先，OpenIM的消息可達性率為100%，可以放心在生產環境中使用。Seq對齊和同步機制確保了OpenIM的消息可訪問性是業界領先的。
IM消息傳遞系統的可靠性通常是指消息傳遞的可靠性，也就是我們經常聽到的“消息必到”，通常用兩個技術指標來表示:消息不丟失、不重復。確保消息發送後能被接收者接收。由於網絡環境的復雜性和用戶在線的不確定性，消息的可靠性(不丟失、不重復)無疑是IM系統的核心指標，也是IM系統實現的難點之壹。壹般來說，IM系統的消息“可靠性”通常是指聊天消息傳遞的可靠性(準確地說，這個“消息”是廣義的，因為還有各種用戶看不到的指令和通知，包括但不限於加入群的通知、添加好友的通知等。為了便於描述，將它們統稱為“消息”)。
從消息發送方和接收方的用戶行為來看，消息的“可靠性”應分為以下幾種情況:
(1)傳輸失敗。在這種情況下，IM系統必須意識到這壹點，並清楚地反饋給發送者。如果郵件發送不成功，發件人可以選擇再試壹次或稍後再試。
(2)傳輸成功。如果接收方在線，它應該會立即收到此消息。如果接收方脫機無法接收消息，它將在聯機後立即接收消息。
(3)消息不能重復。用數學術語來表達就是:“只有這個消息”。如果重復，可能的意思就變了。總之，壹個商業IM系統必須包含消息“可靠性”邏輯才能基本可用，這是IM系統最基本、最核心的邏輯。
互聯網的真實場景比較復雜，但是客戶端大致可以分為兩種情況:(1)發送消息時，接收方在線，可以接收消息；(2)發送消息時，接收方不在線，但登錄後可以接收離線消息。我們使用測試程序來模擬互聯網客戶端的各種場景。根據登錄、發送消息和接收消息的情況，測試客戶端分為以下兩種類型:
(1)開始測試時離線，隨機睡眠0-60秒後登錄，發送消息，接收消息。
(2)開始測試時離線，隨機睡眠0-60秒後登錄，只收消息不發消息。
在實際測試中，有50個客戶端，大約25個(50%概率)客戶端不發送只接收消息，大約25個(50%概率)客戶端發送和接收消息。
發送方式:每個客戶端隨機選擇其他客戶端作為消息接收方；
測試期望:每個成功發送的MsgID都可以在接收到的消息列表中找到。類似地，每個接收到的MsgID都可以在成功發送的消息列表中找到。
具體措施:(1)消息發送成功後，記錄MsgID通過OnSuccess回調；收到新消息後回叫OnRecvNewMessage，記錄MsgID；(2)定期比較兩個消息列表，以確認它們是否完全壹致；
發送100000條數據，其中3條失敗，9999997條成功，接收方成功接收9999997條消息(接收方成功接收消息，寫入本地db，觸發消息回調)。
每壹條成功發送的消息，無論消息發送時接收方的登錄狀態是在線還是離線，對方都能準確接收。
每壹條發送失敗的消息，對方都不會收到。
註意事項:
(1)控制壓力，因為sdk需要寫本地db，客戶端會成為壓力瓶頸。
(2)壓力測試客戶端日誌會影響測試性能。
這個表是壹個IM雲平臺的價格。如果按照月活躍654.38+萬計算，存儲消息三年，每年需要支付654.38+05萬。采用OpenIM只需要購買壹臺雲主機，壹年的費用在80萬左右。