webman: a framework in the Workerman ecosystem

Evidence limits

The only supplied source is the English Workerman Official Manual front page and preface. That page mentions webman exactly once: for HTTP-related services or sites, "webman is strongly recommended." Everything else about webman's own routing, configuration, directory layout, installation command, versions, PHP compatibility, license and support status is unknown from this evidence. This guide marks those points as unknown instead of guessing, and the lifecycle is recorded as unknown.

What this project is

webman is classified here as a framework. It is not a standalone PHP runtime, and it is not a CMS. The manual presents it as part of the Workerman ecosystem, where Workerman is described as an open-source PHP application container written in pure PHP. The manual says Workerman itself is not an MVC framework but a lower-level, general service framework. webman therefore sits on top of that foundation as the HTTP-oriented option.

Two related distinctions matter when you read other material:

• PHP core is the language engine. Workerman and webman are PHP code that runs on it, not replacements for it.
• Framework components and CMS products are different things. webman is framework-level and does not ship Drupal-style content management. Drupal CMS is a product built on PHP, not part of PHP core.

Similarly, Swoole and Open Swoole are distinct projects, and neither is Workerman. Async libraries and framework adapters are not standalone runtimes either. Do not treat names as interchangeable.

Architecture and execution model

The manual describes Workerman as using multiple processes, epoll and non-blocking I/O. Its processes stay resident in memory, and it does not depend on Apache, Nginx or PHP-FPM as a container. It lists TCP, UDP, UNIX sockets, WebSocket, HTTP, WSS and HTTPS among supported protocols. It also lists timers, asynchronous clients and a coroutine section.

The central concept is the Worker. The manual's table of contents lists worker properties such as count, name, protocol and transport. It also lists callbacks such as onWorkerStart, onConnect, onMessage and onClose, plus the runAll interface. A framework on this foundation inherits a persistent worker lifetime. That is the key contrast with the classic request lifetime.

Classic request lifetime versus persistent workers

In the classic PHP-FPM or Apache model, PHP state is built and discarded for each request. Static properties, globals and open objects vanish when the request ends, which hides many mistakes.

In a persistent worker, the process outlives requests. The manual itself notes that this avoids per-request initialization and destruction overhead. The cost is that anything stored in memory can survive into the next request handled by the same worker process.

State leakage and cleanup

State leakage means data from one request being visible to a later request. Typical causes are static properties, global variables, singletons holding user or tenant data, unclosed resources and caches that grow without bound. Habits that are safe under PHP-FPM can then cause incorrect or insecure behavior.

Practical cleanup rules:

• Keep per-request data in local variables or in an object created per request.
• If a static holder is unavoidable, reset it at the start of every request handler.
• Treat user, tenant and session identity as request-scoped, never worker-scoped.
• Put bounded limits on any worker-lifetime cache.
• Plan for restarts. The manual's table of contents includes topics on object and resource persistence, restarting after a number of requests, and smooth restart. Read those pages before relying on long-lived resources.
• Remember that code changes need a worker reload or restart. The manual has a page on code changes not taking effect.

The example below shows the effect with a counter that persists and a user slot that is reset.

Practical use cases

The preface lists instant messaging, IoT, game servers, HTTP services, SOA services and other server software for the Workerman ecosystem. For web work specifically, it points to webman for high-performance HTTP interfaces and sites. Whether webman suits a particular CMS-like or content-heavy site cannot be determined from the supplied source.

Installation approach

The manual's contents list System Requirements, Download and Install, and Start and Stop, but the supplied page does not include their text. webman's own installation steps are therefore unknown here. Follow the official manual for them. The example below uses Workerman directly through Composer so you can observe the persistent-worker model without guessing webman internals. It is a Workerman illustration, not a webman application. The manual states that Workerman supports Linux and Windows, and that Windows has its own notes.

The learning track targets PHP 8.4, with PHP 8.5 planned. Whether the Workerman or webman version you install supports PHP 8.4 is unknown from this source, so a reviewer must verify it before the example is published.

Strengths

• Resident workers avoid per-request bootstrap cost. The manual makes performance claims, which this guide does not repeat or verify.
• The same ecosystem covers HTTP, WebSocket, timers and asynchronous clients.
• The manual describes the core as small, with other features supplied by components.

Limitations

• The supplied evidence says little about webman itself.
• Persistent workers demand discipline about state, resources and restarts.
• Blocking calls can stall a worker that serves many connections. The manual has debugging pages on busy processes.
• The manual's scope statement mentions Workerman 3.x to 5.x, but the current version, support status and license are unknown.

Deployment

The manual indicates Workerman runs its own server processes and has pages on its relationship with Nginx and Apache, getting the real client IP through a proxy, and starting with the system. Exact webman deployment guidance is unknown from this source. For development, bind to 127.0.0.1. Never expose internal service ports publicly without reviewing the official guidance. Put any public entry behind a reviewed reverse proxy.

Next steps

Read the official manual's installation and worker pages, then locate the webman documentation from the same site to fill the unknown items. Run the example only in an isolated environment that has Composer and network access. It is not a browser exercise.

{
  "name": "learnphponline/workerman-state-demo",
  "description": "Persistent worker state demo",
  "type": "project",
  "require": {
    "workerman/workerman": "*"
  }
}

<?php

declare(strict_types=1);

require __DIR__ . '/vendor/autoload.php';

use Workerman\Worker;

final class RequestState
{
    // Survives across requests inside one worker process.
    public static int $served = 0;

    // Must be request-scoped; reset before each request.
    public static ?string $currentUser = null;

    public static function reset(): void
    {
        self::$currentUser = null;
    }
}

// Bound to loopback only, for development.
$worker = new Worker('http://127.0.0.1:8080');
$worker->count = 1;
$worker->name = 'state-demo';

$worker->onMessage = function ($connection, $request): void {
    RequestState::reset();
    RequestState::$served++;

    $connection->send('served=' . RequestState::$served . ' user=none' . "\n");
};

Worker::runAll();

composer install
php server.php start
curl http://127.0.0.1:8080/
curl http://127.0.0.1:8080/
php server.php stop