Domande che ogni sviluppatore di Workerman deve conoscere

1. Limitazioni dell'ambiente Windows

In un sistema Windows, Workerman supporta solo più di 200 connessioni per processo.
In un sistema Windows non è possibile utilizzare il parametro count per impostare processi multipli.
In un sistema Windows non è possibile utilizzare comandi come status, stop, reload, restart, ecc.
In un sistema Windows non è possibile eseguire come processo in background, il servizio si arresta quando si chiude la finestra cmd.
In un sistema Windows non è possibile inizializzare più ascoltatori in un file.
I sistemi Linux non hanno queste limitazioni, si consiglia di utilizzare un sistema Linux per l'ambiente di produzione, mentre per l'ambiente di sviluppo si può scegliere Windows.

2. Workerman non dipende da Apache o Nginx

Workerman è già un contenitore simile ad Apache/Nginx, basta che l'ambiente PHP sia configurato correttamente e Workerman può funzionare.

3. Workerman si avvia da riga di comando

Il modo di avvio è simile ad Apache, utilizzando un comando per avviare (spesso gli hosting web non consentono l'uso di Workerman). L'interfaccia di avvio appare simile a questa

4. I collegamenti lunghi devono includere il heartbeat

È necessario includere heartbeat nei collegamenti lunghi, è necessario includere heartbeat nei collegamenti lunghi, è necessario includere heartbeat nei collegamenti lunghi; ripetere l'importante.
I collegamenti lunghi che non comunicano per lungo tempo potrebbero essere rimossi da nodi di routing, causando la chiusura della connessione.
Spiegazione del heartbeat di Workerman, Spiegazione del heartbeat di GatewayWorker

5. I protocolli del client e del server devono corrispondere per comunicare

Questo è un problema molto comune per gli sviluppatori. Ad esempio, se il client utilizza il protocollo websocket, il server deve utilizzare anche il protocollo websocket (new Worker('websocket://0.0.0.0...')) per stabilire la connessione e comunicare.
Non cercare di accedere all'indirizzo del protocollo websocket dalla barra degli indirizzi del browser, non cercare di utilizzare il protocollo websocket per accedere a una porta TCP pura; i protocolli devono corrispondere.

Il principio qui è simile a dover comunicare con un britannico, dove devi usare l'inglese. Se devi comunicare con un giapponese, devi usare il giapponese. Qui, le lingue sono simili ai protocolli di comunicazione: entrambe le parti (client e server) devono utilizzare la stessa lingua per comunicare, altrimenti non sarà possibile.

6. Possibili cause di connessione fallita

Un problema comune quando si inizia a usare Workerman è il fallimento della connessione del client al server. Le cause sono generalmente le seguenti:

1. Il firewall del server (inclusi i gruppi di sicurezza dei server cloud) blocca la connessione (50% di probabilità di essere questo)
2. I protocolli utilizzati dal client e dal server non corrispondono (30% di probabilità)
3. L'IP o la porta sono stati scritti in modo errato (15% di probabilità)
4. Il server non è avviato

7. Non usare le istruzioni exit, die o sleep

L'esecuzione delle istruzioni exit o die interromperà il processo e mostrerà l'errore WORKER EXIT UNEXPECTED. Naturalmente, se il processo si interrompe, ne verrà immediatamente riavviato uno nuovo per continuare il servizio. Se è necessario restituire un valore, è possibile utilizzare return. L'istruzione sleep farà andare il processo in "sleep mode", durante il quale non verrà eseguita alcuna operazione; il framework smetterà di funzionare e tutte le richieste dei client in quel processo non potranno essere gestite.

8. Non utilizzare la funzione pcntl_fork

pcntl_fork viene utilizzato per creare nuovi processi in modo dinamico. Se viene utilizzato pcntl_fork nel codice dell’applicazione, potrebbe generare processi orfani non recuperabili, causando anomalie nell'applicazione. Inoltre, pcntl_fork nel codice potrebbe influenzare la gestione di eventi come connessioni, messaggi, chiusure di connessione e timer, causando anomalie imprevedibili.

9. Non ci devono essere loop infiniti nel codice dell'applicazione

Non ci devono essere loop infiniti nel codice dell'applicazione, altrimenti il controllo non potrà essere restituito al framework Workerman, impedendo di ricevere e gestire messaggi da altri client.

10. Modifiche al codice richiedono un riavvio

Workerman è un framework residente in memoria, quindi per vedere gli effetti del nuovo codice, è necessario riavviare Workerman.

11. Applicazioni a lungo termine dovrebbero usare il framework GatewayWorker

Molti sviluppatori usano Workerman per sviluppare applicazioni a lungo termine, come la messaggistica istantanea, Internet delle cose, ecc. Si consiglia di utilizzare direttamente il framework GatewayWorker per le applicazioni a lungo termine, poiché è stato progettato per semplificare ulteriormente lo sviluppo di backend per le applicazioni a lungo termine basate su Workerman.

12. Supporto per una maggiore concorrenza
Se il numero di connessioni simultanee supera 1000, assicurati di ottimizzare il kernel Linux e di installare l'estensione event.