Why Webman Outperforms Traditional PHP Frameworks: Architecture & Benchmark Guide

What is Webman?

Webman is a high‑performance HTTP service framework built on Workerman. It replaces the traditional php‑fpm architecture and can be used to develop websites, HTTP APIs, micro‑services, as well as custom processes for WebSocket, IoT, game, TCP, UDP, and Unix socket services.

Philosophy

Provide maximum extensibility and performance with the smallest kernel.

Webman implements only core features (routing, middleware, session, custom‑process interface). All other functionality is supplied by Composer packages, allowing reuse of familiar components such as Laravel’s illuminate/database, ThinkPHP’s ThinkORM, Medoo, etc.

Key Features

High stability – built on the battle‑tested Workerman socket framework.

Extreme performance – typically 10‑100× faster than traditional php‑fpm frameworks and about twice the speed of Go frameworks such as Gin or Echo.

High reusability – most Composer packages work without modification.

Great extensibility – custom processes can implement any Workerman capability.

Simple to learn – usage is similar to conventional PHP frameworks.

MIT license.

Performance Comparison

Traditional PHP framework request flow

nginx/Apache receives the request.

Passes it to php‑fpm.

php‑fpm initializes the environment.

php‑fpm runs extension RINIT hooks.

php‑fpm reads the PHP file (opcache can skip).

php‑fpm parses and compiles to opcode (opcache can skip).

php‑fpm executes opcode.

Framework bootstraps (container, controller, router, middleware, etc.).

Framework connects to database, Redis, etc.

Framework executes business logic.

Framework closes database/Redis connections.

php‑fpm releases resources and destroys symbols.

php‑fpm runs extension RSHUTDOWN hooks.

php‑fpm returns the result to nginx/Apache.

nginx/Apache sends the response to the client.

Webman request flow

Framework receives the request.

Executes business logic.

Returns the result directly to the client.

Without an Nginx reverse proxy, Webman processes only these three steps, giving it a several‑fold performance advantage.

Why traditional PHP/FPM cannot compete with Java or Go: Short‑lived processes repeatedly initialize and destroy memory structures for each request. Blocking I/O causes heavy CPU waste due to process context switches under high concurrency.

Comparison with Go Web Frameworks

With database‑query workloads, Webman is roughly twice as fast as comparable Go web frameworks (data from techempower.com).

Stress‑Testing Guidelines

Factors influencing benchmark results

Network latency between load generator and server (prefer LAN or local testing).

Bandwidth of the load generator.

Whether HTTP keep‑alive is enabled (recommended).

Sufficient concurrency level (increase for external testing).

Appropriate number of Webman worker processes (match CPU count for simple "helloworld", four‑times CPU cores for database‑heavy workloads).

Application performance itself (e.g., avoid external databases).

HTTP keep‑alive

HTTP keep‑alive allows multiple requests and responses to be sent over a single TCP connection, dramatically improving throughput. Disabling it can cause QPS to drop by orders of magnitude. Modern browsers enable it by default.

Enabling keep‑alive in benchmarks

For ab use the -k flag: ab -n100000 -c200 -k http://127.0.0.1:8787/ Other tools such as wrk enable keep‑alive by default.

Why external‑network tests show low QPS?

High latency over the public internet reduces QPS; testing on a LAN or locally yields more representative numbers. If external testing is required, increase concurrency while ensuring sufficient bandwidth.

Performance impact of an Nginx proxy

Nginx consumes system resources and adds communication overhead with Webman, which can lower overall throughput. Mitigation strategies:

Disable Nginx access logs: access_log off; Enable keep‑alive between Nginx and Webman.

Prefer HTTPS only when necessary, as TLS handshake adds CPU and bandwidth cost.

Detecting the performance ceiling

When CPU usage reaches 100 %, the system is likely at its limit. If CPU is still idle, increase concurrency. If QPS does not improve, consider adding more Webman processes or checking network bandwidth.

Benchmark command examples

ab

# 100000 requests, 200 concurrency, keep‑alive enabled
ab -n100000 -c200 -k http://127.0.0.1:8787/

# 100000 requests, 200 concurrency, keep‑alive disabled
ab -n100000 -c200 http://127.0.0.1:8787/

wrk

# 200 concurrent connections for 10 seconds (keep‑alive default)
wrk -c 200 -d 10s http://example.com