深入了解 Poxa:開源的實時通訊解決方案

picture

2024-11-04

深入了解 Poxa:開源的實時通訊解決方案

什麼是 Poxa?

Poxa 是一個開源的 Pusher 服務兼容實現,用 Elixir 語言編寫。它是一個自我託管的 WebSocket 消息服務器,適用於即時消息、通知和其他實時交互功能。

使用 Poxa 的情境

  • 實時聊天系統:用於用戶間的即時通信。
  • 在線遊戲:處理玩家之間的實時互動。
  • 即時通知:如股票價格更新、新聞推送等。
  • 多用戶協作工具:如共享文檔編輯、項目管理等。

為什麼選擇 Poxa?

  • 私有與自定義:自我託管的解決方案,擁有更高的控制權和自定義能力。
  • 開源性:可根據需求修改源代碼。
  • Pusher 兼容:可作為 Pusher 替代品,無需修改已有應用的客戶端代碼。

替代方案

  • Pusher:穩定且易用,但為商業產品,靈活性較少。
  • Firebase Realtime Database:支持實時數據庫功能,但可能有數據隱私問題。
  • Socket.io:完全開源,適合需要高度自定義的場景。

Poxa 的優缺點

優點

  1. 開源與自我託管:可自行部署,增強數據隱私。
  2. Pusher API 兼容:適合替換已有的 Pusher 應用。
  3. 靈活性:支持多種語言和平台。

缺點

  1. 需要自我維護:需自行負責服務器的維護、穩定性與安全性。
  2. 社群支持有限:相較於 Pusher 等商業產品,社群活躍度略遜。
  3. 功能相對簡單:功能和文檔不如商業產品完善。

如何架設 Poxa

基本安裝步驟

Step 1:安裝 Elixir 和 Erlang

可使用 Homebrew 安裝 Elixir 和 Erlang。

brew install elixir
elixir --version
erl -version

Step 2:克隆 Poxa 專案

可以選擇 fork 到自有項目中使用 CAFACA-IO 的版本,或原始版本。

git clone https://github.com/CAFECA-IO/poxa.git
cd poxa

Step 3:安裝並編譯依賴

mix deps.get
mix deps.compile

Step 4: 初始化數據庫

mix do ecto.create, ecto.migrate

Step 5: 配置 Poxa

可創建配置文件,如 dev.config

use Mix.Config

config :poxa,
  http: [ip: {127, 0, 0, 1}, port: 8080],
  app_key: "YOUR_APP_KEY",
  secret: "YOUR_SECRET_KEY",
  app_id: "YOUR_APP_ID"

Step 6: 啟動 Poxa

mix run --no-halt

Step 7: 驗證

訪問 http://localhost:8080,查看控制面板確認運行成功。

Step 8: 客戶端連接

使用 Pusher client SDK 連接到 Poxa,實現消息傳送和接收。

壓力測試配置與結果分析

壓力測試配置

  • Number of Threads (Users):設置為 100 和 500,用來模擬不同用戶數的連接負載。
  • Ramp-Up Period:設置為 10 秒,逐步建立連接,避免瞬時高峰。
  • Loop Count:設置為 Forever,在 10 分鐘時停止測試。

測試結果

以下為 100 用戶和 500 用戶的壓力測試結果,並附有相應的圖表:

100 用戶測試結果

  • 平均響應時間:458 毫秒
  • 中位數響應時間:230 毫秒
  • 90% 響應時間:900 毫秒
  • 最大響應時間:2000 毫秒
  • 錯誤率:2.1%
  • 吞吐量:120 次/秒

500 用戶測試結果

  • 平均響應時間:2,300 毫秒
  • 中位數響應時間:529 毫秒
  • 90% 響應時間:5,587 毫秒
  • 最大響應時間:超過 90 秒
  • 錯誤率:7.4%
  • 吞吐量:95 次/秒

1000 用戶測試結果

  • WebSocket Open Connection:

    • 樣本數量:75,845
    • 平均響應時間:7,252 毫秒
    • 中位數響應時間:3,528 毫秒
    • 90% 響應時間:20,001 毫秒
    • 最大響應時間:21,732 毫秒
    • 錯誤率:19.884%
    • 吞吐量:123.026 次/秒
    • 每秒接收數據量:77.38 KB
  • WebSocket request-response Sampler:

    • 樣本數量:74,845
    • 平均響應時間:0 毫秒(可能為心跳包或空回應)
    • 最大響應時間:621 毫秒
    • 錯誤率:20.007%
    • 吞吐量:0.00004 次/秒
  • 總計(TOTAL):

    • 樣本數量:150,690
    • 平均響應時間:3,650 毫秒
    • 中位數響應時間:532 毫秒
    • 90% 響應時間:20,000 毫秒
    • 最大響應時間:21,732 毫秒
    • 錯誤率:19.945%

圖表分析

  1. 100 用戶測試圖表

    Screenshot 2024-11-01 at 5 36 22 PM Screenshot 2024-11-01 at 5 36 43 PM Response Time Graph Graph Results
    • 圖表顯示,在 100 個用戶情境下,響應時間分佈較均勻,大多數請求在 1 秒以內完成。雖有少數延遲情況,但整體表現穩定。
    • 錯誤率維持在 2.1%,表明系統能夠有效處理該負載下的連接請求。
  2. 500 用戶測試圖表

    Screenshot 2024-11-04 at 5 35 48 PM Screenshot 2024-11-04 at 5 38 01 PM
    • 在 500 用戶情境下,響應時間大幅增加,圖表中顯示的響應延遲曲線有顯著波動,且部分請求超過 90 秒。
    • 錯誤率上升到 7.4%,吞吐量下降,表明系統在高負載下面臨性能瓶頸。
  3. 1000 用戶測試圖表

    Screenshot 2024-11-04 at 5 41 19 PM Screenshot 2024-11-04 at 5 41 41 PM Graph Results
    • 在 1000 用戶情境下,響應時間大幅增加,平均響應時間達到 7,252 毫秒,90% 響應時間達到 20 秒,且部分請求的響應時間高達 21,732 毫秒。
    • 錯誤率高達 19.945%,吞吐量顯著降低,顯示出系統在高並發下的穩定性不足。

性能分析與問題原因

1. 網絡延遲與連接管理

  • 測試顯示,在高負載下的響應時間變異大,延遲明顯增高。這可能是由於網絡連接過多導致資源競爭加劇,使系統無法在實時性要求下有效管理連接。

2. 資源分配不足

  • Poxa 部署在單伺服器上可能導致資源分配不足。CPU 和內存的負載過高會導致延遲增大。考慮到吞吐量的下降,可能需要伺服器擴容或分布式部署來提升性能。

3. 缺少負載均衡

  • 在高負載下,單一實例難以應對 500 用戶的連接。可以考慮通過引入負載均衡來分散流量,並提高系統的容錯能力。

性能分析方法

  1. 資源監控

    • 使用監控工具(如 Grafana 和 Prometheus)來觀察 CPU、記憶體和網絡的資源使用情況,尤其是在高並發情境下的瓶頸點。
  2. 數據分析與可視化

    • 記錄各階段測試數據,分析不同併發下的響應時間分佈、錯誤率和吞吐量。使用可視化工具幫助理解系統在不同負載下的表現。
  3. 異常情境測試

    • 在模擬高延遲、丟包等網絡異常情境下測試 Poxa,確保在不同網絡條件下的穩定性。

性能優化方向

1. 增加並發測試及監控

  • 測試更高併發數(如 1000 用戶),並使用監控工具實時查看伺服器資源使用情況,找出系統瓶頸。

2. 優化資料庫與快取

  • 檢查資料庫連接池配置,適當增加連接池上限。利用快取技術減少高頻數據查詢對系統的負擔。

3. 負載均衡與擴容

  • 引入負載均衡:在多台伺服器上部署 Poxa,並通過負載均衡(如 NGINX 或 HAProxy)分散流量,以減少單一伺服器的負載。
  • 橫向擴容:在高負載場景下,考慮增加伺服器實例,以便應對更高的併發需求並確保系統穩定性。

4. 優化 WebSocket 連接管理

  • 優化連接數量:限制單用戶的 WebSocket 連接數量,避免過多的連接對伺服器資源造成不必要的壓力。
  • 實施空閒連接清理機制:設置連接超時或空閒連接清理,定期釋放不活躍的 WebSocket 連接資源。
  • 連接重試和後退機制:在高負載下,如果連接無法建立,可考慮實施重試和後退策略,以減輕伺服器壓力。

5. 使用更高效的資料庫配置

  • 資料庫分區:對於大量連接請求的情境,可考慮對資料庫進行分區,以減少單一資料庫的負載。
  • 索引與查詢優化:對於頻繁查詢的資料添加索引,並確保查詢語句經過優化,以加快數據檢索速度。

6. 啟用資料快取

  • 使用 Redis 或 Memcached:對於頻繁讀取的資料,可以使用 Redis 或 Memcached 快取服務,減少對資料庫的壓力,從而提高響應速度。
  • 應用層快取:在伺服器端實現應用層的快取,對於靜態資料或頻繁使用的資料,通過快取進行儲存,以減少伺服器的計算負擔。

7. 精確的錯誤管理與日誌監控

  • 詳細的日誌:實現詳細的日誌記錄,便於追蹤高錯誤率情況下的問題來源,特別是針對連接超時、消息未送達等錯誤進行分析。
  • 錯誤通知系統:在錯誤發生時,自動觸發通知或警報,便於即時排查和修復問題,確保系統穩定性。

結語

通過對 Poxa 進行壓力測試及性能分析,我們可以發現其在高併發環境下的瓶頸和需要改進之處。此次測試結果顯示,當用戶數量達到 500 時,系統的響應時間顯著增大,且錯誤率也相對偏高,說明了 Poxa 的部署在應對大量 WebSocket 連接時存在性能限制。

可能可以通過優化資源配置、引入負載均衡、加強連接管理和錯誤處理機制,可以有效提升 Poxa 的穩定性和性能,從而更好地應用於需要高併發、低延遲的實時通訊場景中。

在未來的性能測試中,建議持續監控伺服器資源使用情況、定期進行異常情境測試,並根據具體應用場景逐步調整配置,以確保 Poxa 在實際應用中的穩定性和效率。這些優化措施將有助於打造出一個高性能的自我託管實時通訊解決方案,滿足更廣泛的業務需求。

emily_avatar

Tzuhan Liang

软件工程师

热衷于举重的爱好者,可以毫不费力地硬举七十公斤的重量,转而投入公路自行车运动,并变成了一个热爱碳水化合物的丰满人士。现在重新调整训练计画,以找回失去的肌肉。

查看作者的其他文章

分享到

回上页