Why LAMP Fails Microservices and How Modern PHP Frameworks Supercharge Performance

Overview

PHP has been in production for more than 29 years and a large number of MVC frameworks exist. They can be grouped into three categories:

Internally developed frameworks – custom frameworks built by companies for their own business needs.

Open‑source PHP frameworks – e.g., Yii, Laravel, CodeIgniter, Zend Framework, Symfony.

C extensions – compiled extensions such as Yaf and Phalcon, which are harder to modify.

All of these run on a L(A)MP stack (Linux, Apache/Nginx, MySQL/MariaDB, PHP) where the web server (commonly Nginx) forwards requests to php‑fpm. Discarding php‑fpm and Nginx is unrealistic in most production environments.

Limitations of traditional L(A)MP for micro‑service workloads

php‑fpm

uses a synchronous, blocking process model. For each request the framework is re‑initialized, the process then idles while the framework objects are destroyed, and the CPU is consumed by this “create‑destroy‑create” cycle. Consequently a single machine’s throughput is limited.

Why not switch the programming language

Changing the language would require abandoning existing code, retraining developers, rewriting business logic, and rebuilding the operations stack – costs that are prohibitive for most teams.

Practical solution

More than 90 % of typical workloads are I/O‑bound. Improving I/O multiplexing and replacing the synchronous php‑fpm model with an asynchronous, non‑blocking approach can raise per‑node throughput dramatically. At the time of writing no engineering‑grade PHP MVC framework provides this capability, which is why the modern Webman framework is suggested as a viable alternative.

Problems with the php‑fpm working mode

Nginx uses the epoll event model; a single worker can handle many concurrent connections.

Each php‑fpm worker can process only one request at a time.

The master process only monitors workers and writes logs.

Client requests are first parsed by an ELB and then by Nginx.

Before handling a request a php‑fpm worker must re‑initialize the MVC framework, then release all resources after the request finishes.

Under high concurrency the number of available workers becomes insufficient, causing Nginx to return HTTP 502 errors.

Process‑switching overhead is large; on a 4‑core, 8 GB server only about 16 workers can be effectively utilized.

Benchmark comparison

Goal

Compare the QPS of a minimal “echo hello world” script built with Yii2 on PHP 5.6 and PHP 7 under identical hardware.

Compare the QPS of an existing service (Redis, MongoDB, advertising APIs, business APIs) on PHP 5.6 and PHP 7.

Tool

ApacheBench (ab). Example command:

ab -n 50000 -c 10 -k http://www.tinywan.com/

Hardware

AWS c4.xlarge instance (4 CPU, 8 GB RAM).

Hello‑world benchmark

PHP 5.6 / Yii2

n      c   qps      avg(ms)  CPU
10000  1   662.73   1.509    6%
50000  10  1435.35  6.967    76%
500000 20  1577.16 13.375    83%
500000 50  1626.09 145.953   89%

PHP 7 / Yii2

n      c   qps      avg(ms)  CPU
10000  1   854.81   1.170    18%
50000  10  2008.32  4.979    62%
500000 20  2186.90  9.145    65%
500000 50  2304.98 21.692    69%
500000 200 2331.93 85.766    69%

Existing service benchmark

1 × Redis GET

1 × MongoDB query

2 × advertising APIs

2 × business APIs

PHP 5.6 / Yii2 (service)

n    c   qps   avg(ms)   CPU
100  1   4.16   240.168   9%
5000 5   15.36  325.502   46%
5000 10  18.72  534.141   83%
5000 50  19.03  2627.159  99%

PHP 7 / Yii2 (service)

n    c   qps   avg(ms)   CPU
100  1   3.51   284.876   5%
5000 5   17.23  290.129   21%
5000 10  32.36  309.057   40%
5000 20  52.94  377.784   82%
5000 40  55.52  720.433   91%

Conclusions

Upgrading from PHP 5.6 to PHP 7.0 improves Yii2 performance by roughly 43 %.

The same upgrade raises the performance of the existing service by about 170 %.

Simply moving business logic to PHP 7 yields a substantial throughput gain without changing the framework.