How WebMan Leverages Workerman for High‑Performance PHP HTTP Services

Overview

WebMan is an HTTP service framework based on Workerman, designed for building web sites or HTTP APIs. It supports routing, middleware, automatic injection, multi‑application, custom processes, and works with existing Composer components without modification. Its key traits are low learning cost, simplicity, ultra‑high performance and stability.

In simple terms, webman is a memory‑resident application service framework built on workerman. It runs in a multi‑process blocking mode using an IO multiplexing model (select/poll or epoll depending on the installed event extension).

Execution Modes

Single‑Process Mode

One service process handles a request sequentially: it waits for network IO, processes business logic (which may involve database, file, or other network IO), then sends the response. This mode cannot sustain high concurrency and will quickly return 502 errors under load.

Multi‑Thread/Coroutine Mode

A master process spawns a dedicated thread (or coroutine) for each request, allowing higher concurrency than the single‑process mode. Thread creation and context switching incur overhead, and deadlocks are possible; coroutines (user‑space lightweight threads) mitigate these issues.

IO Multiplexing Mode

Workers use select/poll or epoll to monitor multiple sockets. When a socket is not ready, the worker continues to accept other requests. Once the socket becomes readable, the worker processes the request exclusively. epoll provides edge‑triggered notifications, avoiding the busy‑polling required by select/poll.

EventLoop Mode

Borrowing the eventLoopFactory from the ReactPHP ecosystem, WebMan can run an event‑driven loop similar to Node.js or ReactPHP. Requests are queued; when IO becomes ready, the worker is notified and resumes processing. This model excels in performance but is less suited for complex business logic due to callback‑hell concerns.

Why WebMan Lacks a Database Connection Pool

WebMan’s workers operate under an IO‑multiplexing model where each worker holds a single database connection for the lifetime of the request. Because the worker is fully occupied by the business code during the IO‑wait period, it cannot release the connection to a pool and fetch another one for a different request. Consequently, a traditional connection pool would provide no benefit in this architecture.

Performance Testing

Test environment: Intel i5‑7360U CPU @ 2.30 GHz (2 cores, 4 threads), 8 GB RAM, 4 WebMan workers.

Test Code

Controller app/controller/Index.php simulates mixed read/write database operations and returns JSON data.

/**
 * Data IO business simulation
 * @return Response
 */
public function db()
{
    $nameList = ['james','lucy','jack','lilei','lily'];
    $hobbyList = ['football','basketball','swimming'];
    $name = $nameList[array_rand($nameList)];
    $hobby = $hobbyList[array_rand($hobbyList)];
    if (mt_rand(0,5) >= 2) { // 0‑1 read, 2‑5 write
        $insertId = Db::table('test')->insertGetId([
            'name' => $name,
            'age'  => rand(20,100),
            'sex'  => ['m','f'][array_rand(['m','f'])],
            'hobby'=> $hobby,
        ]);
        $data = ['id' => $insertId];
    } else {
        $data = Db::table('test')->where('hobby',$hobby)->first();
    }
    return json(['msg'=>'success','data'=>$data]);
}

Benchmark Commands

ab -c 200 -n 50000 -k http://0.0.0.0:8787/index/db

ab -c 500 -n 50000 -k http://0.0.0.0:8787/index/db

ab -c 798 -n 50000 -k http://0.0.0.0:8787/index/db

Results

Across all three concurrency levels the request rate stayed around 3,300‑3,500 requests per second, with average request latency between 60 ms (200 concurrency) and 230 ms (500 concurrency). No failed requests were observed, and the QPS remained stable around 3.5 k on a 2‑core machine, indicating that WebMan can comfortably handle typical database‑intensive workloads.

Original article source: https://segmentfault.com/a/1190000039377021