今天正式用了下workerman發(fā)現(xiàn)有的時候吃帶寬吃的好多啊
大概是這么個過程
用的websocket
其中有個客戶端需要每隔一秒發(fā)送一個ws.send 一個消息、服務(wù)器響應(yīng) 回復(fù)給全部客戶端 在線列表【含頭像以及昵稱數(shù)據(jù)】
其他應(yīng)該是沒啥會這樣消耗這么多帶寬的地方
ps 已經(jīng)統(tǒng)計 帶寬出現(xiàn)峰值時候才只有137個人在線啊
我服務(wù)器帶寬買的才12M 嚇?biāo)牢伊?
這可咋整？
貼下帶寬監(jiān)控 ：
15個回答
打賞
帶寬占用大和workerman沒直接關(guān)系，和你業(yè)務(wù)有關(guān)。
你可以根據(jù)自己的業(yè)務(wù)估算需要多大帶寬。
比如你說的137人在線，其中一個人發(fā)了一個圖片，圖片10kB。
137個人同時看到聊天信息下載圖片，瞬間帶寬 137*10kB/S=1.3MB/S=10Mbit/S。
但是這個你不能說是workerman的問題
-
1619443919 2016-12-17咱們workenman 用wesocket協(xié)議 返回客戶端的包數(shù)據(jù)最大是多少M啊 我擔(dān)心我返回在線用戶列表數(shù)據(jù)過多 里面有頭像和昵稱等數(shù)據(jù) 造成發(fā)送不出去或是報錯
-
-
walkor大大
幫我看看 150人左右的 這個workerman的status 正常不
8核的
每個gateway占用的內(nèi)存貌似不高 每個的請求數(shù)卻又這么多
有點暈乎
[attach]466[/attach]
- 暫無評論
gateway的connections鏈接數(shù)不代表全部是客戶端的鏈接，connections包含了該進程內(nèi)所有tcp的鏈接數(shù)，包括gateway與Worker的內(nèi)部通許鏈接，gateway與register的鏈接。
手冊有這部分介紹 http://doc3.workerman.net/advanced/status.html
所以截圖的connections部分統(tǒng)計是正常的，每個gateway有4個BusinessWorker的鏈接和1個Register的鏈接。
請求數(shù)多少是否正?？梢宰约核?，我不清楚你的業(yè)務(wù)，這個沒法幫你
- 暫無評論
walkor大大
那為何重啟workerman 請求數(shù)就掉下去了 不重啟居就一直下不去
理論上當(dāng)時沒有用戶進聊天室呢
對于這個每個gateway請求數(shù)的含義 連接數(shù)又具體代表啥子含義
- 暫無評論
對于服務(wù)器未正式投入工作或是只有少量用戶在聊天室內(nèi)
total_request 也就是各個gateway的請求數(shù) 顯示很多的話
可能的原因
幫我分析分析唄
- 暫無評論
按照你的業(yè)務(wù)邏輯，一個客戶端每秒發(fā)一個請求到workemran，那一天也要8萬的請求呢。
看到你截圖里的請求數(shù)也正常啊
我剛用測試服務(wù)器又測試了下
發(fā)現(xiàn) 請求數(shù)只要一上去了 就下不來了
20161220 凌晨2點的監(jiān)控 并且我確定截此圖后
服務(wù)器沒有客戶端連接了
[attach]469[/attach]
然后 今天下午3點多 我再次查看下監(jiān)控
截圖如下
[attach]470[/attach]
請求數(shù)還是下不去
主要是 若是只有少量請求數(shù) 那應(yīng)該是正常的 但是沒有客戶端鏈接服務(wù)器
仍然有 700+的請求數(shù)
哪里來的？
我猜測 gateway的請求數(shù) 只要一上去 就下不來了
重啟workeman 可以讓請求數(shù)降下來
- 暫無評論
