Designing High‑Concurrency Systems with PHP Object Pooling and Swoole IPC

The core concept of pooling is to exchange memory for speed by reusing pre‑created objects, thereby reducing the overhead of frequent object creation and lowering resource costs; this technique is essential for high‑concurrency system design.

In PHP, traditional in‑process connection pools suffer from several drawbacks: each worker process maintains its own pool, leading to resource waste when processes are created or destroyed; the number of pools grows with the variety of resources (MySQL, Redis, etc.); and in PHP‑FPM the pool is often useless because it is created and destroyed per request.

Short connections generate a large number of TIME_WAIT sockets, exhausting temporary ports; converting short connections to long connections dramatically reduces TIME_WAIT counts and improves performance.

Building on the long‑connection idea, the article proposes a three‑layer architecture: short‑connection → long‑connection → connection pool → cross‑process connection pool, allowing all worker processes to share a single pool of long‑lived connections.

Swoole’s inter‑process communication (IPC) provides two mechanisms—Unix Socket and SysV message queue. Unix Socket offers zero‑copy, fully in‑memory communication, while SysVmsg is less flexible and rarely used.

To address the need for a shared pool across N workers, the solution adopts asynchronous non‑blocking IPC via Unix Socket, implemented with Swoole’s event loop (swoole_event_add) and epoll, enabling millions of reads/writes per second.

The article compares three Swoole process models (Task sub‑process, UserProcess, ProcessPool) in a table, highlighting that only ProcessPool offers asynchronous non‑blocking communication and low coupling, making it suitable for the shared‑pool design.

By replacing the default blocking communication with socket‑based asynchronous IPC, a dedicated UserProcess can maintain all connection pools (MySQL, Redis, etc.) independently of the workers, allowing even PHP‑FPM to benefit from the shared pool.

Performance tests show CPU usage dropping from 17% to 12% and average request latency decreasing from 12.31 ms to 10.09 ms after deploying the cross‑process Redis pool, with further gains expected as more pools are integrated.

Author: Li Xudong, backend engineer with experience at Baidu and 58.com, specializing in PHP, Go, and C++ backend development.