How Open Swoole works

Open Swoole is different from the traditional stateless PHP model, a Open Swoole application runs in CLI mode like how Node.js does but with a different design using coroutines that don't introduce callback hell.

OpenSwoole enables you to keep your application running in memory, allowing you to run PHP servers in a stateful manner, reducing the latency of requests because any bootstrapping or application startup can be done before a server is ready to take requests.

You can either run OpenSwoole directly on your network or use Apache or Nginx with a proxy pass through setup to accept requests. OpenSwoole simplifies the PHP server setup as you don't need to run a separate HTTP server, it is all handled at the PHP level, replacing the need for PHP-FPM.

Open Swoole adopts a multi-process, event-driven, and asynchronous design, this means OpenSwoole has a specific process model to achieve all of this. The high-performance and immense networking throughput is achieved by taking advantage of multiple CPU cores, worker processes and the concurrency of coroutines.

At a high-level, OpenSwoole starts a Master process which runs the event-loop threads, another processes is started which is called the Manager process, this process manages each worker, if a worker fails it will be restarted by the Manager process. A worker is where your main business logic will be executed. And Timer functionality which is a thread is handled as part of the Master process.

How Open Swoole works

PHP Swoole internal

The differences between Open Swoole with PHP-FPM the traditional PHP model are:

• Open Swoole supports TCP, UDP and UnixSocket
• Open Swoole uses Non-blocking I/O mode with epoll or kqueue
• Open Swoole forks several worker processes based on CPU core number to utilise all CPU cores.
• Open Swoole supports Long-live connections for WebSocket server or TCP/UDP server.
• Open Swoole supports more server-side protocols: TCP/UDP/HTTP/HTTP2/WebSocket
• Open Swoole preload PHP files into memory.
• Open Swoole can manage and reuse the status in memory with PHP Swoole Memory Management Modules.
• Coroutine based concurrency compare with waterfall in PHP-FPM.

OpenSwoole Server Structure

Master process

Master process is the first entry point for the OpenSwoole Server.

Reactor threads in Master process

Reactor threads are created in the Master process to handle client side network connections and network I\O.

Manager process

Manager process create or destroy Worker processes and Task Worker processes.

Worker process

Worker process receive data from the Reactor threads and execute business logic, then send back the response to Reactor threads.

Your application code should be run within Worker processes.

Task Worker process

Task processes are used to offload code which will block the event-loop or coroutines that are running.

Task Worker processes receive data from Worker process and send back the result to the Worker process.

A Worker process sends data to a Task worker with the following functions:

• OpenSwoole\Server->task
• OpenSwoole\Server->taskCo
• OpenSwoole\Server->taskwait
• OpenSwoole\Server->taskWaitMulti

A Task worker process sends results back to Worker process with: OpenSwoole\Server->finish.

Interested with Open Swoole? Get Started with Open Swoole now!