php -m|grep event查看是否安裝嗎？如果不安裝event會導(dǎo)致哪些后果？

php -m| grep event可以看php是否安裝event擴(kuò)展。
php start.php status 里顯示 event-loop:\Workerman\Events\Event 則是啟用。

不裝event擴(kuò)展當(dāng)連接數(shù)超過1000時，超過的部分將無法收到消息，無法檢測到連接斷開等事件，導(dǎo)致連接數(shù)增多，消息收不到或延遲，內(nèi)存增大。

項目是運(yùn)行在docker容器里的。優(yōu)化Linux內(nèi)核是優(yōu)化宿主機(jī)還是容器的？

客戶端A和B鏈接成功之后加入一個組，我后端服務(wù)重啟之后，客戶端B發(fā)送組內(nèi)消息 客戶端A出現(xiàn)消息延遲這種什么情況？

保險起見linux內(nèi)核都優(yōu)化下。
延遲問題根據(jù)你提供的信息無法判斷延遲原因，可能是業(yè)務(wù)有什么耗時操作導(dǎo)致延遲，也可能是沒裝event擴(kuò)展連接數(shù)超過1000限制導(dǎo)致的延遲

一個問題一個問題的解決

event安裝了 收不到消息、內(nèi)存、連接數(shù)這些目前沒發(fā)現(xiàn)問題，connections也降下來了。

現(xiàn)在就是客戶端和服務(wù)器端都設(shè)置了10秒進(jìn)行心跳檢測。服務(wù)器10發(fā)送給客戶端。客戶端10秒給服務(wù)器發(fā)送心跳檢測。但是現(xiàn)在打日志看到同一個用戶在同一秒內(nèi)能發(fā)送10個左右的心跳檢測，這種是客戶端導(dǎo)致的嗎？但是當(dāng)那個用戶重新鏈接之后就是10秒一次了

客戶端問題

postman收到的那就是服務(wù)端發(fā)的

客戶端顯示發(fā)送了，過了幾秒在Gateway 的自定義Events里onMessage里才接收到，中間這幾秒異常怎么查呢？

是客戶端發(fā)送失敗還是網(wǎng)絡(luò)延遲或者是后端workerman處理時卡到哪里了？

onMessage里記錄下總的執(zhí)行時間，看下是不是業(yè)務(wù)哪里太慢了

onMessage記錄總時間包括wokerman處理鏈接的時間嗎？就像nginx代理API那樣，PHP能記錄nginx執(zhí)行時間嗎？
現(xiàn)在是onMessage收到之后能很快就返回結(jié)果，但是在客戶端點擊發(fā)送到onMessage收到消息中間會出現(xiàn)延遲，不知道是客戶端的問題還是網(wǎng)絡(luò)問題或者服務(wù)端workerman問題，這種怎么查證？？？？

onMessage 是收到消息觸發(fā)的，不包括之前消息接收時間。
你可以嘗試把nginx去掉試下排除nginx問題，暫時去掉所有業(yè)務(wù)排除業(yè)務(wù)問題。

我直接通過端口啟動的，然后通過域名加端口訪問的時候還是要先走nginx解析域名的是吧？但是我客戶端建立socket鏈接之后每次發(fā)送消息還要再走nginx解析嗎？中間這塊的時間不應(yīng)該是workerman的解析嗎？

域名加端口不走nginx，除非端口是nginx端口

既然不走nginx。那現(xiàn)在情況是 客戶端執(zhí)行send之后到我gateway Events的onMessage第一次輸出日志，有時候中間的時間會是十幾秒，這種怎么查？是網(wǎng)絡(luò)問題還是服務(wù)端workerman服務(wù)問題？

可能是有慢業(yè)務(wù)影響，所以讓你去掉所有業(yè)務(wù)試下。或者下載一個workerman-chat試下

沒法去掉。只有正式環(huán)境才會有延遲，也不是一直有，就是當(dāng)人多起來的時候會出現(xiàn)。

打了日志，進(jìn)入onMessage的時候記錄開始時間[毫秒] 然后在業(yè)務(wù)處理完之后做日志記錄減去開始時間就沒有大于20毫秒的。但是在使用的時候確實還是出現(xiàn)卡頓，還有什么辦法查證嗎？

event擴(kuò)展確認(rèn)安裝成功，帶寬足夠

之前客戶端有些問題會創(chuàng)建一堆的連接，現(xiàn)在做的客戶端做的心跳檢測是10秒一次，但是我服務(wù)器收到的是有一大批都是每個連接每秒好幾次ping事件。這些ping事件多了即使業(yè)務(wù)處理的快也會造成一定的堆積，business處理不過來導(dǎo)致卡頓吧？

安卓創(chuàng)建socket連接，當(dāng)出現(xiàn)斷網(wǎng)或者異常的時候socket連接會重新創(chuàng)建，但是之前的socket連接沒有銷毀，不管是之前的還是新的連接用的都是同一個變量名，然后當(dāng)網(wǎng)絡(luò)連接恢復(fù)的時候就客戶端會出現(xiàn)觸發(fā)很多次的onopen，是不是意味著斷網(wǎng)的時候創(chuàng)建的那些socket又活過來了，然后這些socket還能正常發(fā)送請求？用的是不是還是同一個clientid？

處理ping沒有什么業(yè)務(wù)邏輯，一般都很快，應(yīng)該不是ping造成的?？聪路?wù)器帶寬

是不是一個clientid可以自己打日志看

客戶端onopen打開的時候不是同一個clientid

帶寬圖放上去了，目前5M的帶寬。但是之前的時候帶寬都是在4以下

出現(xiàn)卡頓的時候看下實時帶寬，你截圖的是被整體平均過的。

圖中出方向的帶寬超過5M了，目前來看是不是需要增加帶寬了？

帶寬不夠出現(xiàn)卡頓很正常

就目前的話，增加帶寬增加到多少合適？同時在線用戶數(shù)多的時候也不到1000

你看監(jiān)控里大概需要多少就設(shè)置多少

不是說上圖的是被整體平均過的嗎，那也就是說有的肯定要比圖中的要高？那增加的時候應(yīng)該要比圖中的要高出一部分吧

對

出的帶寬使用多少其實也是與我服務(wù)器返回內(nèi)容大小有關(guān)吧，我返回的數(shù)據(jù)少了占用的就少

對