Problemas que los desarrolladores de Workerman deben conocer

1. Limitaciones en el entorno Windows

En un sistema Windows, Workerman solo soporta más de 200 conexiones por proceso.
En Windows, no se puede utilizar el parámetro count para configurar múltiples procesos.
En Windows, no se pueden usar comandos como status, stop, reload, restart, etc.
En Windows, no se puede ejecutar como un proceso en segundo plano; el servicio se detiene al cerrar la ventana cmd.
En Windows, no se puede inicializar múltiples escuchas en un solo archivo.
En sistemas Linux no hay estas limitaciones; se recomienda usar un sistema Linux en entornos de producción, mientras que se puede optar por usar Windows en entornos de desarrollo.

2. Workerman no depende de Apache o Nginx

Workerman en sí mismo ya es un contenedor similar a Apache/Nginx; siempre que el entorno PHP esté OK, Workerman podrá funcionar.

3. Workerman se inicia desde la línea de comandos

La forma de iniciar es similar a Apache, utilizando un comando para iniciar (generalmente el espacio web no puede usar Workerman). La interfaz de inicio es similar a la siguiente:

4. Las conexiones largas deben incluir un latido

Las conexiones largas deben incluir un latido, las conexiones largas deben incluir un latido, las conexiones largas deben incluir un latido, es importante repetirlo tres veces.
Las conexiones largas que no se comunican durante un tiempo prolongado pueden ser eliminadas por los nodos de enrutamiento, lo que causa que se cierren las conexiones.
Descripción del latido de Workerman, Descripción del latido de gatewayWorker

5. El protocolo entre el cliente y el servidor debe coincidir para comunicarse

Este es un problema muy común entre los desarrolladores. Por ejemplo, si el cliente utiliza el protocolo websocket, el servidor también debe utilizar el protocolo websocket (el servidor new Worker('websocket://0.0.0.0...')) para poder conectarse y comunicarse.
No intentes acceder al puerto del protocolo websocket desde la barra de direcciones del navegador, ni intentes acceder al puerto TCP desnudo con el protocolo websocket; los protocolos deben coincidir.

El principio aquí es similar a que si deseas comunicarte con un británico, debes usar inglés. Si deseas comunicarte con un japonés, debes usar japonés. Aquí, el lenguaje es similar a los protocolos de comunicación; ambas partes (cliente y servidor) deben usar el mismo lenguaje para poder comunicarse, de lo contrario, no podrán hacerlo.

6. Posibles causas de la falla de conexión

Un problema muy común al comenzar a utilizar Workerman es que el cliente no puede conectarse al servidor. Las razones son generalmente las siguientes:

1. El firewall del servidor (incluidos los grupos de seguridad de servidores en la nube) está bloqueando la conexión (tiene un 50% de probabilidad).
2. El protocolo utilizado entre el cliente y el servidor no coincide (30% de probabilidad).
3. La IP o el puerto están mal escritos (15% de probabilidad).
4. El servidor no ha sido iniciado.

7. No utilices instrucciones exit, die o sleep

Ejecutar las instrucciones exit o die en el negocio hará que el proceso termine y muestre el error WORKER EXIT UNEXPECTED. Por supuesto, si el proceso termina, se iniciará inmediatamente un nuevo proceso para continuar con el servicio. Si necesitas devolver un valor, puedes usar return. La instrucción sleep hará que el proceso se detenga; durante este tiempo de inactividad, no se ejecutará ninguna tarea, y el marco también dejará de funcionar, lo que hará que todas las solicitudes de los clientes en ese proceso no puedan ser atendidas.

8. No utilizes la función pcntl_fork

pcntl_fork se utiliza para crear nuevos procesos de forma dinámica; si se utiliza pcntl_fork en el código del negocio, podría generar procesos huérfanos que no se pueden recuperar, lo que causaría excepciones en el negocio. Usar pcntl_fork en el negocio también afectará el manejo de conexiones, mensajes, cierre de conexiones, temporizadores, entre otros eventos, lo que provocará excepciones no predecibles.

9. No debe haber bucles infinitos en el código de negocio

No debe haber bucles infinitos en el código de negocio; de lo contrario, la autoridad no podrá devolverse al marco de Workerman, lo que impedirá recibir y procesar otros mensajes de clientes.

10. Cambiar el código requiere reiniciar

Workerman es un marco residente en memoria; cambiar el código requiere reiniciar Workerman para ver los efectos del nuevo código.

11. Se recomienda usar el marco GatewayWorker para aplicaciones de conexiones largas

Muchos desarrolladores utilizan Workerman para desarrollar aplicaciones de conexiones largas, como mensajería instantánea, Internet de las cosas, etc. Para aplicaciones de conexiones largas, se recomienda utilizar directamente el marco GatewayWorker, que está diseñado específicamente sobre la base de Workerman, haciendo que la administración del backend de aplicaciones de conexiones largas sea más simple y fácil de usar.

12. Soporta una mayor concurrencia

Si el número de conexiones concurrentes de negocio supera los 1000 en línea al mismo tiempo, asegúrate de optimizar el núcleo de Linux y instalar la extensión de eventos.