Questions que tout développeur Workerman doit connaître

1. Limitations de l’environnement Windows

Dans un système Windows, Workerman ne supporte qu'un seul processus pour 200+ connexions.
Il est impossible d’utiliser le paramètre count pour définir plusieurs processus dans Windows.
Les commandes status, stop, reload, restart, etc. ne sont pas disponibles dans Windows.
Il n'est pas possible d’exécuter un processus en arrière-plan sous Windows ; lorsque la fenêtre cmd est fermée, le service s'arrête.
Il n'est pas possible d'initialiser plusieurs écouteurs dans un seul fichier sous Windows.
Il n'y a pas de telles restrictions dans les systèmes Linux, il est recommandé d'utiliser un système Linux pour l'environnement de production, tandis que l'environnement de développement peut choisir d'utiliser Windows.

2. Workerman ne dépend pas d’Apache ou de Nginx

Workerman est en fait un conteneur similaire à Apache/Nginx et peut fonctionner tant que l’environnement PHP est OK.

3. Workerman est démarré via la ligne de commande

La méthode de démarrage est similaire à l'utilisation d'Apache avec une commande (la plupart des espaces web ne peuvent pas utiliser Workerman). L'interface de démarrage est similaire à celle-ci :

4. Les connexions persistantes doivent avoir un cœur battant

Les connexions persistantes doivent avoir un cœur battant, les connexions persistantes doivent avoir un cœur battant, les connexions persistantes doivent avoir un cœur battant. C'est important, donc cela est répété trois fois.
Si une connexion persistante n’échange pas de données pendant longtemps, elle sera nettoyée par un nœud de routage et la connexion sera fermée.
Documentation sur le cœur battant de Workerman, Documentation sur le cœur battant de GatewayWorker

5. Le protocole entre le client et le serveur doit correspondre pour communiquer

C'est un problème très courant pour les développeurs. Par exemple, si le client utilise le protocole websocket, le serveur doit également utiliser le protocole websocket (le serveur new Worker('websocket://0.0.0.0...')) pour pouvoir se connecter et communiquer.
Ne tentez pas d’accéder au port websocket dans la barre d'adresse du navigateur, et ne tentez pas d'accéder à un port TCP brut via le protocole websocket. Les protocoles doivent correspondre.

Le principe ici est similaire à celui d'une communication avec un Britannique ; vous devez utiliser l'anglais. Si vous voulez communiquer avec un Japonais, vous devez utiliser le japonais. Les langues pratiquées agissent comme des protocoles de communication ; les deux parties (le client et le serveur) doivent utiliser la même langue pour communiquer, sinon la communication échouera.

6. Causes possibles de l’échec de la connexion

Un problème courant lors de l'utilisation de Workerman est l’échec de la connexion entre le client et le serveur. Les raisons sont généralement les suivantes :

Le pare-feu du serveur (y compris le groupe de sécurité du serveur cloud) bloque la connexion (50 % de chance que ce soit cela)
Le protocole utilisé par le client et le serveur n'est pas cohérent (30 % de chance)
L'adresse IP ou le port est mal écrit (15 % de chance)
Le serveur n'est pas démarré

7. Ne pas utiliser les instructions exit, die ou sleep

L'exécution des instructions exit ou die par le biais d'une logique métier entraîne la fermeture du processus, ce qui affiche une erreur WORKER EXIT UNEXPECTED. Naturellement, le processus redémarrera immédiatement un nouveau processus pour continuer à servir. Si un retour est nécessaire, vous pouvez utiliser return. L'instruction sleep mettra le processus en sommeil et pendant ce temps aucun traitement de la logique métier ne sera exécuté, le cadre cessera également de fonctionner, ce qui empêchera le traitement de toutes les demandes des clients de ce processus.

8. Ne pas utiliser la fonction pcntl_fork

pcntl_fork est utilisée pour créer dynamiquement de nouveaux processus. Si elle est utilisée dans le code métier, cela peut générer des processus orphelins non récupérables, ce qui peut entraîner des anomalies dans le service. L’utilisation de pcntl_fork dans le code métier affectera également le traitement des connexions, des messages, de la fermeture de connexions, des temporisateurs, et d'autres événements, entraînant des anomalies imprévisibles.

9. Pas de boucle infinie dans le code métier

Évitez les boucles infinies dans le code métier, car cela entraînera l'incapacité de céder le contrôle au cadre Workerman, empêchant ainsi le traitement des messages d'autres clients.

10. Redémarrage nécessaire après modification du code

Workerman est un cadre résident en mémoire ; pour voir les effets du nouveau code, il faut redémarrer Workerman après modification.

11. Pour une application à connexion persistante, il est conseillé d'utiliser le cadre GatewayWorker

De nombreux développeurs utilisent Workerman pour développer des applications à connexion persistante, telles que la messagerie instantanée ou l’Internet des objets. Pour ces applications à connexion persistante, il est conseillé d'utiliser directement le cadre GatewayWorker, qui est une encapsulation simplifiée de Workerman, facilitant encore plus le développement d'applications de backend à connexion persistante.

12. Support pour une concurrence plus élevée

Si le nombre de connexions concurrentes dans le service dépasse 1000 simultanément en ligne, il est impératif d'optimiser le noyau Linux et d'installer l'extension event.