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

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

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

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

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

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

一個(gè)問(wèn)題一個(gè)問(wèn)題的解決

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

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

客戶(hù)端問(wèn)題

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

處理ping沒(méi)有什么業(yè)務(wù)邏輯，一般都很快，應(yīng)該不是ping造成的。看下服務(wù)器帶寬

是不是一個(gè)clientid可以自己打日志看

客戶(hù)端onopen打開(kāi)的時(shí)候不是同一個(gè)clientid

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

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

圖中出方向的帶寬超過(guò)5M了，目前來(lái)看是不是需要增加帶寬了？

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

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

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

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

對(duì)

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

對(duì)