Questions Every Workerman Developer Must Know

1. Limitations in Windows Environment

In a Windows system, Workerman supports only over 200 connections per single process.
In a Windows system, the count parameter cannot be used to set multiple processes.
In a Windows system, commands such as status, stop, reload, and restart cannot be used.
In a Windows system, there is no support for daemon processes; the service will stop once the cmd window is closed.
In a Windows system, it is not possible to initialize multiple listeners in a single file.
Linux systems do not have the above limitations. It is recommended to use a Linux system for production environments, while a Windows system can be used for development environments.

2. Workerman Does Not Depend on Apache or Nginx

Workerman itself is a container similar to Apache/Nginx; as long as the PHP environment is set up, Workerman can run.

3. Workerman Is Started via Command Line

The startup method is similar to Apache, initiated through command (generally, web hosting services cannot run Workerman). The startup interface looks like the one below:

4. Long Connections Must Include Heartbeat

Long connections must include heartbeat; long connections must include heartbeat; long connections must include heartbeat. Important things should be said three times.
Long connections that do not communicate for a long time may be cleaned up by routing nodes, resulting in connection closures.
Heartbeat Explanation for Workerman, Heartbeat Explanation for GatewayWorker

5. Client and Server Protocols Must Match for Communication

This is a common issue for developers. For example, if the client uses the WebSocket protocol, the server must also use the WebSocket protocol (new Worker('websocket://0.0.0.0...')) to establish a connection and enable communication.
Do not attempt to access a WebSocket protocol port from the browser's address bar; do not attempt to access a raw TCP protocol port using WebSocket protocol. The protocols must correspond.

The principle here is similar: if you want to communicate with an English speaker, you must use English. If you want to communicate with a Japanese person, you must use Japanese. The language here is akin to a communication protocol, and both parties (client and server) must use the same language to communicate; otherwise, communication will be impossible.

6. Possible Reasons for Connection Failure

A common issue when first using Workerman is that the client fails to connect to the server. The reasons generally include:

  1. The server firewall (including cloud server security groups) is blocking the connection (50% chance this is the issue)
  2. The protocols used by the client and server are inconsistent (30% chance)
  3. The IP or port is incorrect (15% chance)
  4. The server is not started

7. Do Not Use exit, die, or sleep Statements

Using exit or die statements in business operations will cause the process to exit and display the WORKER EXIT UNEXPECTED error. While the process does exit, a new process will immediately restart to continue the service. If a return is needed, it can be executed using return. The sleep statement will put the process to sleep, during which no business operations will execute, and the framework will also stop running, resulting in an inability to handle all client requests for that process.

8. Do Not Use pcntl_fork Function

pcntl_fork is used to dynamically create new processes; using pcntl_fork in business code could lead to unrecoverable orphan processes, resulting in abnormal business behavior. Additionally, using pcntl_fork in business could affect connection handling, message processing, connection closures, timers, and other events, leading to unpredictable exceptions.

9. Avoid Infinite Loops in Business Code

Do not include infinite loops in business code; otherwise, control cannot be returned to the Workerman framework, preventing the processing of other client messages.

10. Restart Required After Code Changes

Workerman is a long-running framework; changes to code require restarting Workerman to see the effects of the new code.

11. Long Connection Applications Should Consider Using GatewayWorker Framework

Many developers use Workerman to develop long connection applications, such as instant messaging and IoT, so it is recommended to use the GatewayWorker framework directly, which is specifically designed for long connection applications on top of Workerman, making backend development much simpler and easier to use.

12. Support for Higher Concurrency

If the number of concurrent connections exceeds 1000 online simultaneously, please make sure to optimize the Linux kernel and install the event extension.