你好，大神，用咱們的GatewayWorker做即時通訊并發(fā)問題

華哥更新于2020-09-10

你好，我們用GatewayWorker做即時通訊的后端，用redis 做了一部分緩存，同時消息存儲到 mongodb ,業(yè)務(wù)接口用 mysql 這塊

我們做并發(fā)測試，發(fā)現(xiàn) 4核的服務(wù)器每秒連接人數(shù) 基本在 1W左右可以的，但用前端給后端每秒發(fā)送數(shù)據(jù) 發(fā)現(xiàn)socket 基本上每秒只能處理 10條左右數(shù)據(jù)的下發(fā)，前端每秒 100條數(shù)據(jù)發(fā)數(shù)據(jù)，導致全部堆積到后端，基本上延時 1-2給小時才能下發(fā)完，到現(xiàn)在也不清楚原因原因

問下大神，咱們 GatewayWorker 每秒理論數(shù)據(jù)下發(fā)至客戶端在多少條？想這樣的每秒100條消息，服務(wù)器沒有下發(fā)都堆積到哪里了？

 3205  4 0

4個回答

華哥 2020-09-09

咱們 GatewayWorker 理論每秒下發(fā)至客戶端數(shù)據(jù)量在多少條？前端毫秒發(fā)送到 socket， GatewayWorker處理不過來，全部在堆積

暫無評論

華哥 2020-09-09

我們也有再看 mysql redis mongodb 都沒有達到瓶頸并發(fā)數(shù) ，看控制面板監(jiān)控也qps才到10個左右，就是堆積數(shù)據(jù)太嚴重，消息處理不過來，想我們現(xiàn)在一個4核服務(wù)器，也才支持 150人數(shù)，每秒不能超過 15條數(shù)據(jù)，要不就堆積，消息延時嚴重

keytehu 2020-09-10

有可能 mysql redis mongodb 這塊太慢了，去掉所有存儲，直接轉(zhuǎn)發(fā)看下效果。

walkor 2020-09-10

打賞

壓測的業(yè)務(wù)邏輯是什么？廣播給1萬人？

暫無評論

華哥 2020-09-10

邏輯很簡單，用一個客戶端向sokcet 發(fā)消息（毫秒循環(huán)發(fā)送一秒100條數(shù)據(jù)），GatewayWorker 向APP客戶端下發(fā)數(shù)據(jù)，基本上發(fā)現(xiàn)，socket （廣播給不到10人的群）下發(fā)最大也就是每秒10條的量，單一接收客戶端只能每秒最多接收 10條數(shù)據(jù)